Il controllo della versione è ottimo per (almeno) three quattro cose: backup, condivisione del codice tra gli sviluppatori, individuazione e correzione dei bug e monitoraggio dell'avanzamento.

1. Backup . Se non altro, è il backup su steroidi. Hai l'intera cronologia dello sviluppo, ogni commit è un'istantanea dell'intero codice con un id (numero di revisione), una descrizione, data / ora, informazioni utente. Ed è semplice confrontare i file tra le revisioni. Se non altro, è più veloce di un semplice backup (solo le modifiche ai file vengono inviate e archiviate) e contiene metadati molto più utili. Perché reinventare questo?

2. Condivisione di codice tra gli sviluppatori . Se hai almeno due sviluppatori che lavorano sullo stesso prodotto contemporaneamente, non vedo alcun altro modo per condividere in modo affidabile e coerente le modifiche al codice e unirle. Invio di zip per posta?

3. Individuazione e correzione dei bug . Quando i clienti segnalano un bug per una versione specifica del prodotto, è possibile ottenere rapidamente la vera istantanea di origine per riprodurla e risolverla. È difficile riprodurre bug se la tua fonte è diversa da quella del cliente. Chiedi loro di inviare l'eseguibile in modo da poterlo smontare? Inoltre, se hai problemi a identificare la causa di un bug, puoi utilizzare VCS per individuare la revisione esatta in cui è stata introdotta.

4. Monitoraggio dell'avanzamento . Quando impegni il lavoro in istantanee, consente a te (e al tuo manager) di tenere traccia dei progressi sulle implementazioni delle funzionalità e sullo stato dei bug aperti. I sistemi VC sono inoltre facilmente integrabili con i sistemi di tracciamento e i sistemi continuous integration . È quasi impossibile mantenere un livello di qualità per qualsiasi altra cosa diversa da un progetto di hobby, a meno che tu non abbia un VCS.

Una volta che siete tutti d'accordo sul fatto che nessuno sviluppo di software dovrebbe mai essere fatto al di fuori di un VCS (non mi mancherà nemmeno per un progetto di hobby), allora potete discutere le caratteristiche di un (leggermente più complicato) DVCS (la seguente parte copiata in modo esplicito da Wikipedia ):

• Ogni utente ha la sua copia locale del repository (ed efficacemente una copia di backup)
• Consente agli utenti di lavorare in modo produttivo anche quando non connesso in una rete
• Rende le operazioni molto più veloci poiché non è coinvolta alcuna rete
• Consente la partecipazione ai progetti senza richiedere autorizzazioni dalle autorità del progetto
• Consente il lavoro privato, in modo che gli utenti possano utilizzare il loro sistema di controllo di revisione anche per le prime bozze che non vogliono pubblicare
• Evita di fare affidamento su una singola macchina fisica come singolo punto di errore

"Hai mai trovato utile il pulsante" annulla "? Oh, quindi sei d'accordo che dovremmo usare un controllo di versione allora?"

Quando ho iniziato a utilizzare il controllo della versione, la funzione principale a cui ero interessato era la possibilità di "annullare" i miei errori e tornare a una versione precedente. Tutti possono apprezzare un pulsante Annulla. Il controllo della versione concesso può fare molto di più.

Inizia con le basi:

In primo luogo un VCS protegge gli sviluppatori da loro stessi e gli uni dagli altri - se non servisse altro che consentire a due o più sviluppatori di lavorare sulla stessa base di codice in modo relativamente sicuro sarebbe di enorme valore (e sono stato in una squadra dove i lavori dei giorni precedenti sono stati sovrascritti da un po 'di copia noncurante).

In secondo luogo fornisce una pista di controllo - una cronologia - puoi tornare indietro e vedere chi ha cambiato cosa e quando e puoi tornare indietro e recuperare il codice che hai eliminato perché non era più necessario o appropriato quando si scopre che sarà essere necessario, dopotutto.

In terzo luogo ti dà un punto di riferimento - la fonte definitiva è il codice impegnato (nel mondo reale è un po 'più complicato, specialmente con DVCS, ma per il gusto di questa discussione è abbastanza vicino). Se si dispone di un backup corretto del repository, è necessario proteggere la risorsa dell'azienda.

Queste tre cose dovrebbero essere "it" per vendere VCS - se un gestore non può vedere un valore sufficiente nel tempo sopra indicato per trovare un altro gestore.

Una volta che hai venduto VCS (che sono, dopotutto, solo di uso per i team di sviluppo dove il numero di sviluppatori è maggiore di zero), allora la questione del perché DVCS, per esempio, SVN o TFS e l'ulteriore domanda di se lavorare in casa o usare un servizio in hosting come Kiln o Bitbucket o Github (che è privato se paghi) è piuttosto più profondo e più dipendente dal contesto.

VCS

Spiega semplicemente il concetto di backup . I backup ti permettono di vedere a cosa stavi lavorando in un dato momento. Racconta come prima i programmatori VCS usavano copiare i loro progetti in modo compulsivo, in genere per salvare ogni buona e stabile release che avevano, quindi quando le cose andavano male avevano un buon punto di riferimento su quando le cose funzionavano, confrontarle con le ultime cose e vedere dove loro o qualcun altro hanno incasinato e sistemano più facilmente semplicemente osservando le differenze invece degli interi due backup del progetto.

In breve : i VCS ti consentono di salvare i backup del tuo lavoro e ti danno la capacità di vedere solo le differenze tra i backup.

DVCSs

Per quanto riguarda il controllo della versione distribuita, spiega come il tipico controllo di versione usato per ha bisogno di un server e una connessione Internet e tutti si sono stancati di questo perché era più lento e tutti hanno lavorato su un singolo backup, se un incasinato ha incasinato il progetto per tutti, quindi con il controllo della versione distribuita tutti possono lavorare sul proprio backup nella propria macchina senza una connessione Internet, e tutti sono felici perché nessuno ha problemi con il backup mentre lavorano e possono preoccuparsi di condividere il loro lavoro più tardi quando hanno finito.

Un altro buon esempio è che a differenza di un VCS centralizzato in cui esiste un solo backup, se la macchina con il backup prende fuoco ci sono ancora altri backup completi da aggirare (almeno uno per ogni sviluppatore).

In breve : i DVCS ti consentono di lavorare nel tuo backup senza che tutti debbano essere stipati in un singolo server e si preoccupino per gli altri cambiamenti dopo hai finito con le tue cose. Inoltre, non accade nulla se la macchina del repository principale prende fuoco .

Lavoro principalmente con ingegneri (non sviluppatori di per sé, ma scrivono codice)

Il punto principale, quando spiego loro del controllo della versione, è la possibilità di annullare e gestire il tuo codice / documentazione / qualsiasi cosa e semplificare la collaborazione con altri sviluppatori / scrittori / etc ...

Questo è un buon punto di vendita - ed è stata la ragione principale per cui ho usato un VCS per tutto il mio lavoro, anche gli altri vantaggi: avere una cronologia, un repository che può essere facilmente supportato ...

La maggior parte di loro piace l'idea e la trova abbastanza utile, adottandola per i propri progetti (specialmente se coinvolge la collaborazione con altri ingegneri).

Quando cerchi di convincere qualcuno di qualcosa, devi sempre provare a provarlo dal loro punto di vista.

Il tuo project manager ha un obiettivo semplice: completare i progetti in tempo e budget.

Se al momento non stai utilizzando il controllo della versione, il tuo team di sviluppo sta risolvendo i problemi che il controllo della versione risolve a mano. Tutti questi problemi sono stati ben enumerati da altre risposte, quindi non li coglieremo qui.

Ciò che devi fare è spiegare al tuo project manager che il team sta spendendo X di ore ogni settimana risolvendo manualmente i problemi che il GIT potrebbe risolvere automaticamente o, diciamo, il 0.1 * X di ore di sviluppo.

Non avvicinarti per motivi che rendono GIT la tua vita più facile o la vita dei tuoi colleghi sviluppatori più facile, avvicinala dal punto di vista che GIT spedirà il software più veloce ed economico.

Mi piace la descrizione di @ Buttons840 come un pulsante di annullamento per la base di codice. Potrebbe anche essere utile confrontarlo con una versione (meno frustrante) di Word o la funzione "Revisioni" di InDesign. Nella mia esperienza, riduce decisamente la necessità per una persona di andare in giro a dire agli altri di non toccare i file X, Y e Z per le prossime ore, il che è utile per fare le cose.

Ho anche trovato le informazioni sulla versione a grana fine incredibilmente utili per correggere / aggirare i bug. Ripongo il numero di versione SVN (tramite la proprietà $ Id) in quasi tutti i file di dati che ho generato. In questo modo, se (quando?) Viene trovato un bug, è banale identificare i file con potenziali problemi e rigenerarli o far sì che altri codici compensino il bug.

Se non usi il controllo di versione, come fai a sapere come ricostruire il tuo ambiente di produzione?

1 Persone diverse (tester, sviluppatori) cercheranno le stesse informazioni in luoghi diversi

che porta a DUPLICARE DATI che non è più sincronizzato.
   Il controllo della versione è il modo più semplice per eliminare i dati duplicati.

2 Se usi il controllo di versione, è facile garantire che l'ambiente di produzione corrisponda a ciò che si trova nel controllo di versione.

In questo modo è facile rilevare se un problema è dovuto a una brutta build (prod non corrisponde al controllo della versione), o un bug di progettazione o di codifica (prod corrisponde al controllo della versione).

Il controllo della versione semplifica l'assegnazione di un numero di versione a ciascuno ambiente di test e naturalmente ci si aspetta che la produzione abbia un numero di rilascio inferiore rispetto a test o sviluppo e test di avere un numero di rilascio inferiore rispetto allo sviluppo. Se questo non fosse il caso, parte del codice non è stata testata correttamente ..

Anche se rilasci software, la seguente caratteristica di un VCS è piuttosto essenziale: supponi che il tuo cliente trovi un bug. Lo sviluppo attuale del software è probabilmente in uno stato molto diverso rispetto alla versione che il cliente ha. Forse il bug è stato risolto, forse no, ma in ogni caso il software attuale non è in uno stato che puoi semplicemente spedire al cliente.

Un VCS rende banale tornare alla versione che è stata spedita al cliente, correggere il bug che stava richiedendo, costruirlo e spedirgli una versione rivista. Tutto questo senza disturbare lo sviluppo attuale, senza dover spedire una versione con caratteristiche non terminate / instabili o altri bug introdotti a causa del nuovo sviluppo incompleto.

Inoltre, un VCS ti consente di riportare questa correzione nel nuovo ramo di sviluppo se il bug è ancora presente anche lì.

Con una strong disciplina puoi probabilmente gestirlo senza VCS per una squadra molto piccola, ma usarne una ti farà risparmiare tempo e denaro. Molto probabilmente ti aiuterà anche a mantenere i tuoi clienti.

Se la tua azienda ha più di due persone, probabilmente hai un documento word o un documento Excel che si trova da qualche parte modificato da più persone. E a volte queste persone fanno copie locali, intraprendono un viaggio di lavoro, ecc. O il documento viene inviato via email dopo ogni cambiamento.

Se si dispone di un file di questo tipo, alcune modifiche apportate a qualcuno sono andate perse in passato o andranno perse in futuro. Oppure la gente pensa di aver perso dei cambiamenti, ma non può provarlo. Oppure vorrebbero vedere chi ha fatto cosa cambia quando e perché. Questo è esattamente il problema che risolve un VCS.

Quando scegli software / librerie open source, avere un repository DVCS è sicuramente un vantaggio nei criteri di selezione.

1) Possiamo clonare l'intero repository, non devi preoccuparti del progetto o il suo sito web è morto.

2) Le persone sono più propense a inviare correzioni di bug tramite richiesta pull, comportano una correzione rapida dei bug per problemi urgenti.