Quando si tratta di progetti molto piccoli (solo pochi sviluppatori), quanto sono efficaci i sistemi distribuiti di controllo delle versioni (ad es., git) rispetto ai sistemi con un repository centrale?
Mi piace l'idea di avere un repository centrale perché sembra molto più elegante e organizzato. Tuttavia, dopo aver visto Google Talk di Linus Torvalds, ho i miei dubbi. Tuttavia, tutti questi vantaggi sono davvero notevoli con un progetto così piccolo?
DVCS non significa che non puoi avere un repository centrale. Non ho idea di come così tante persone riescano a capirlo. I possibili flussi di lavoro svn sono un sottoinsieme di possibili flussi di lavoro git, quindi se vuoi iniziare a utilizzare git semplicemente come questo , non c'è niente che ti fermi. Tuttavia, il contrario non è vero se si desidera utilizzare le funzionalità distribuite in seguito. Personalmente, preferisco avere opzioni disponibili che non potrei mai usare, piuttosto che trovare successivamente voglio usare un'opzione che non è disponibile.
Dipende in gran parte dai tuoi sviluppatori.
Se i tuoi sviluppatori sono distribuiti (più sedi, fusi orari diversi, eventualmente disconnessi per periodi di tempo (viaggi, ecc.)), allora i sistemi di controllo di versione distribuiti hanno un lotto di vantaggi. Sono stato nella sfortunata situazione di lavorare su un sistema di controllo della versione centralizzato su grandi distanze e diversi fusi orari in cui il check-in e il branching erano molto lenti, e il risultato è che tutti smettono di usare il controllo della versione correttamente. La curva di apprendimento per DVCS è più elevata, ma in situazioni distribuite i benefici superano spesso la curva.
Se gli sviluppatori si trovano tutti nello stesso ufficio e lavorano alle stesse ore con connessioni velocissime al server, il check-in / out e la ramificazione sono rapidi e facili. In tal caso, si passa alla curva di apprendimento e alle preferenze: se i tuoi sviluppatori sono tutti con le vecchie mani di Subversion, non c'è un motivo in più per passare a un DVCS. Se sono tutti entusiasti di passare a un DVCS, lo impareranno abbastanza velocemente.
Tutto ciò presuppone che:
Solitamente lavoro da solo, ma sono fermamente convinto di tutto ciò che sta passando attraverso Mercurial . Mi consente di lavorare su diversi compiti, con diverse scadenze di sviluppo, ma di essere ancora in grado di rispondere rapidamente alle esigenze di una nuova funzionalità del cliente. Rende così facile avere diversi rami diversi, quasi non ci penso più. Con SVN (e CVS e RCS e SCCS) la fusione branching era così dolorosa che avrei preferito che il lavoro sui canali radicali fosse svolto senza anestetico.
Ho un sito web in cui ho due non-tecnici che modificano i template di Django e simili, e avevano bisogno di circa 5 minuti di formazione (e un paio di script) per poter usare hg per aggiornare, commit e push alla staging e quindi alla produzione. A loro piace particolarmente il server web integrato che mostra chi ha fatto cosa e quando.
Penso che i vantaggi di un sistema di controllo della versione distribuita siano evidenti su qualsiasi scala. Da ora in poi mi riferirò a git, dal momento che questo è il DVCS con il quale ho più esperienza, ed è più facile da dire e leggere rispetto a DVCS.
Vedo i vantaggi dei sistemi di controllo delle versioni centralizzati come un sottoinsieme dei vantaggi di git. Se vuoi avere un repository centrale con git, vai avanti. Può essere su un server, se vuoi, proprio come il tuo server SVN; o può essere su un disco di rete, o anche una chiavetta USB. Puoi connetterti al tuo repository centrale commit, proprio come fai con CVS; oppure puoi passare la giornata a lavorare nel parco senza una connessione Internet, impegnarti tutto ciò che desideri, quindi inviarlo al tuo server alla fine della giornata. Preferisco quest'ultimo.
Il mio team di sviluppo è piccolo, variando tra 3-5 sviluppatori a seconda del progetto su cui stiamo lavorando. Il nostro ambiente di lavoro ha strane limitazioni che rendono difficile l'implementazione di un sistema centralizzato. Invece usiamo Git per permetterci di coordinare il nostro lavoro tra le varie reti indipendenti in cui ci sviluppiamo. Il vero vantaggio di Git, o di qualsiasi DVCS, è che ti lascia smettere di pensare in termini di risorse di sviluppo fisico: server, sviluppatori, parchi; e ti libera di pensare esclusivamente in termini di rami e tempo, che sono le vere dimensioni nello spazio VCS.
Questo è tutto ciò che devo dire che è un po 'originale, qui ci sono alcuni link che dovrebbero dimostrarsi più istruttivi:
Forse un'altra risposta esaustiva che ho fatto qui ti aiuterà a capire come funzionano i DVCS (ha diagram = P): Sono un disadattato di Subversion, perché dovrei considerare o non considerare Mercurial o Git o qualsiasi altro DVCS?
Non è solo un controllo coordinato su un insieme comune di file. Le funzionalità di versioning di VCS sono estremamente utili quando stai facendo qualsiasi tipo di sviluppo "in rabbia". Indicatori distintivi sulle versioni e la possibilità di tenere traccia delle modifiche nel corso della vita dell'applicazione vengono subito in mente. La maggior parte dei sistemi di compilazione automatizzati (bamboo, hudson, teamcity, ecc.) Presuppongono che tu lavorerai con un VCS.
Per inciso, ho resistito all'introduzione del git al lavoro, poiché semplicemente non mi fido di alcune delle persone con cui lavoro per essere in grado di usarlo in modo competente. Subversion (o CVS) si adatta perfettamente al nostro ambiente.
Leggi altre domande sui tag version-control