Gestione di Repo usando Git o SVN

Question

Gestione di Repo usando Git o SVN

#1 da (4 voti)
#2 da (2 voti)

-3

Abbiamo diversi progetti in corso e dobbiamo capire come gestire i repository.

La situazione attuale è che il progetto A è in produzione, in un Repore di SVN A. Il progetto B è in sviluppo per un altro cliente ed è in realtà un progetto A con alcune funzionalità aggiuntive, in un Repo B. SVN Quindi ogni volta che abbiamo una correzione su A, dobbiamo aspettare un po 'per far verificare la correzione. Nel frattempo, B continua a essere in fase di sviluppo, quindi dopo un po ', la base di codice sarà un po' diversa. Quindi, dopo che la correzione è stata verificata, devo risalire manualmente al commit in A, copiare / incollare il codice in B (perché sono in repository diversi). L'intero processo sta sprecando il mio tempo. E ci saranno più clienti in arrivo, quindi non voglio avere la situazione che devo copiare / incollare il codice su più progetti (repository).

Stiamo discutendo se dovremmo passare a Git o continuare a utilizzare SVN. Se utilizzi Git, possiamo creare rami per il codice base, e quindi ogni client può essere abbinato a un ramo, tuttavia, l'intero concetto di ramo di master/develop/feature-1,2,3/release-v1,2,3 ... potrebbe collassare. So che il ramo esiste anche in SVN

Qual è il modo pulito per organizzare questa situazione?

git project-management svn

posta Thai Tran 06.02.2018 - 09:42

fonte

2 risposte

Leggi altre domande sui tag git project-management svn

Controllo del codice sorgente con più repository specifici del cliente Angolare 5- Dove dovrebbe sedersi il codice di logout?

score 4 · Answer 1

Essendo utente sia di SVN che di GIT, direi che una volta abituato a SVN, ci vuole del tempo per abituarsi a GIT a causa della fondamentale differenza di essere centralizzati / decentralizzati tra loro. Una volta passato quel periodo, il vantaggio che ho provato con Git su SVN che:

Il versioning e la ramificazione richiedono meno sforzi.
Se non hai accesso al "server" base di codice per un po 'di tempo, è più facile gestire il repository come sul tuo computer locale e puoi commutare le modifiche in qualsiasi momento.

Tuttavia mi sento ancora più a mio agio nell'usare SVN per un tipo di ambiente "centralizzato" in cui è necessario caricare continuamente le modifiche nel repository centrale. Anche i file binari specialmente con le grandi dimensioni, SVN è la scelta migliore. Al momento di passare da SVN a GIT per progetti esistenti, devi anche pensare alla "cronologia dei file"

score 2 · Answer 2

Il nostro progetto è passato da SVN a Git circa due anni fa e, a essere onesti, non vorrei tornare indietro. Esistono alcuni strumenti di migrazione ingegnosi che consentono di importare la cronologia di commit SVN in Git, quindi nulla viene perso lì. L'approccio distribuito di Git ha funzionato piuttosto bene anche per noi: usiamo Gitlab come "master repository" da cui attinge il nostro CI ecc.

Un serio vantaggio che vedrei nel tuo caso è la possibilità di selezionare facilmente le correzioni ecc. dal tuo "progetto A" al "progetto B" impostando "progetto B" come una succursale del progetto A. Don Dimentica che puoi "etichettare" determinati punti nel tuo ramo come "release v1", "release v1.1", "release v2" ecc. rendendo meno necessario creare un nuovo ramo per ogni versione (a meno che tu non trovi un bug che deve essere corretto nel rilascio "v1.1" - quindi puoi creare un ramo, correggere il bug, rilasciare "v1.1b" - e poi selezionare anche la correzione sul tuo ramo master)