Ecco una copia di una risposta che ho fatto di alcune domande duplicate da allora cancellate su Git vs. SVN (settembre 2009).
Meglio? A parte il solito link WhyGitIsBetterThanX , sono diversi:
uno è un VCS centrale basato su una copia economica per filiali e tag l'altro (Git) è un VCS distribuito basato su un grafico di revisioni. Vedi anche Concetti chiave di VCS .
Quella prima parte ha generato alcuni commenti male informati fingendo che lo scopo fondamentale dei due programmi (SVN e Git) sia lo stesso, ma che siano stati implementati in modo abbastanza diverso.
Per chiarire la differenza fondamentale tra SVN e Git , vorrei riformulare:
SVN è la terza implementazione di un controllo di revisione : RCS, quindi CVS e infine SVN gestiscono le directory dei dati con versione. SVN offre funzionalità VCS (etichettatura e unione), ma il suo tag è solo una copia della directory (come un ramo, tranne per il fatto che non si "dovrebbe" toccare nulla in una directory di tag) e la sua unione è ancora complicata, attualmente basata su meta -dati aggiunti per ricordare ciò che è già stato unito.
Git è una gestione del contenuto dei file (uno strumento creato per unire i file), evoluto in un vero sistema di controllo della versione , basato su un DAG ( Directed Acyclic Graph ) di commit, in cui i rami fanno parte della storia dei dati (e non dei dati stessi ) e dove i tag sono veri metadati.
Dire che non sono "fondamentalmente" diversi perché puoi ottenere la stessa cosa, risolvere lo stesso problema, è ... semplicemente falso su così tanti livelli.
- se hai molte fusioni complesse, eseguirle con SVN sarà più lungo e più soggetto a errori. se devi creare molti rami, dovrai gestirli e unirli, ancora più facilmente con Git che con SVN, specialmente se è coinvolto un numero elevato di file (la velocità diventa importante)
- se si dispone di fusioni parziali per un lavoro in corso, si trarrà vantaggio dall'area di gestione temporanea Git (indice) per impegnare solo ciò di cui si ha bisogno, riporre il resto e passare a un altro ramo.
- se hai bisogno di sviluppo offline ... bene con Git sei sempre "online", con il tuo repository locale, qualunque sia il flusso di lavoro che vuoi seguire con altri repository.
Ancora i commenti su quella vecchia risposta (cancellata) insistevano:
VonC: Stai confondendo la differenza fondamentale nell'implementazione (le differenze sono molto fondamentali, siamo entrambi chiaramente d'accordo su questo) con la differenza di scopo.
Sono entrambi strumenti usati per lo stesso scopo: ecco perché molti team che in precedenza hanno utilizzato SVN sono stati in grado di scaricarlo con successo a favore di Git.
Se non risolvessero lo stesso problema, questa sostituibilità non esisterebbe.
, a cui ho risposto:
"sostituibilità" ... termine interessante ( utilizzato nella programmazione informatica ).
Ovviamente, Git non è certo un sottotipo di SVN.
Puoi ottenere le stesse caratteristiche tecniche (tag, branch, merge) con entrambi, ma Git non ti ostacola e ti consente di concentrarti sul contenuto dei file , senza pensare allo strumento stesso.
Certamente non puoi (sempre) semplicemente sostituire SVN con Git "senza alterare nessuna delle proprietà desiderabili di quel programma (correttezza, compito svolto, ...)" (che è un riferimento alla suddetta definizione di sostituibilità ):
- Uno è uno strumento di revisione esteso, l'altro un vero sistema di controllo della versione.
- Uno è adatto a progetti monolitici di dimensioni medio-piccole con un semplice flusso di lavoro di fusione e (non troppe) versioni parallele. SVN è sufficiente a tale scopo e potresti non aver bisogno di tutte le funzionalità di Git.
- L'altro consente progetti di medie e grandi dimensioni basati su più componenti ( un repository per componente ), con un numero elevato di file da unire tra più rami in un flusso di lavoro di unione complesso, versioni parallele nei rami, retrofit di fusioni e così via. Potresti farlo con SVN, ma con Git stai molto meglio.
SVN semplicemente non può gestire nessun progetto di qualsiasi dimensione con alcun flusso di lavoro di unione. Git can.
Ancora una volta, la loro natura è fondamentalmente diversa (il che porta quindi a una diversa implementazione ma non è questo il punto).
Uno vede il controllo di revisione come directory e file, l'altro vede solo il contenuto del file (al punto che le directory vuote non si registrano nemmeno in Git!).
L'obiettivo generale generale potrebbe essere lo stesso, ma non è possibile utilizzarli allo stesso modo, né è possibile risolvere la stessa classe di problemi (in ambito o complessità).