Un buon esempio di qualcuno che si adatta a quella descrizione potrebbe essere un project manager.

L'altro giorno mi è stato chiesto dal mio capo "che cos'è questa cosa di Github e perché è importante?" Ha alcuni progetti proprietari quindi avrebbe bisogno di hosting privato e mi sono trovato in difficoltà a spiegare oltre il solito: i VCS rendono banale la collaborazione, forniscono una cronologia e un "backup" di tutti i tuoi dati e ti consentono di registrare le modifiche atomiche in una base di codice . Nella mia mente stavo pensando "è quasi come se dovessi usare un DRVS per capire davvero quanto sia benefico".

Ho finito per indicarlo a BitBucket perché ti danno un numero illimitato di repository privati ​​(dovevo anche spiegare cos'è un repository).

Qualcuno ha davvero buoni esempi concreti di come un VCS ha salvato il culo o semplificato la vita, ecc. - In sostanza, come venderesti un DVSC a qualcuno che non ha familiarità con la programmazione, ma non un programmatore di professione?

Il controllo della versione è ottimo per (almeno) tre quattro cose: backup, condivisione del codice tra sviluppatori, ricerca + correzione di bug e tracciamento dei progressi.

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

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

3. Ricerca e correzione di bug . Quando i tuoi clienti segnalano un bug per una specifica versione del prodotto, puoi ottenere rapidamente lo snapshot di origine reale per riprodurlo e correggerlo. È difficile riprodurre i bug se la tua fonte è diversa da quella del cliente. Chiedete loro di inviare l'eseguibile in modo da poterlo smontare? Inoltre, se si riscontrano problemi nell'identificare la causa di un errore, è possibile utilizzare VCS per individuare la revisione esatta in cui è stato introdotto.

4. Tracciamento dei progressi . Quando esegui il commit del tuo lavoro in istantanee, consente a te (e al tuo manager) di tenere traccia dei progressi nelle implementazioni delle funzionalità e nello stato dei bug aperti. I sistemi VC sono inoltre facilmente integrabili con i sistemi di localizzazione e i sistemi di integrazione continua . È quasi impossibile mantenere un livello di qualità per qualsiasi cosa diversa da un progetto hobby, a meno che tu non abbia un VCS.

Una volta che tutti avete concordato che nessuno sviluppo software dovrebbe mai essere fatto al di fuori di un VCS (non me lo perderei nemmeno per un progetto di hobby), allora potete discutere le caratteristiche di un DVCS (leggermente più complicato) (la parte seguente è palesemente copiata da Wikipedia ):

• Ogni utente ha la propria copia locale del repository (ed effettivamente una copia di backup)
• Consente agli utenti di lavorare in modo produttivo anche quando non sono connessi a una rete
• Rende la maggior parte delle operazioni molto più veloce poiché non è coinvolta alcuna rete
• Consente la partecipazione a progetti senza richiedere autorizzazioni dalle autorità di progetto
• Consente il lavoro privato, quindi gli utenti possono utilizzare il proprio sistema di controllo delle revisioni 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 versione allora?"

Quando ho iniziato a utilizzare il controllo versione, la caratteristica principale che mi interessava 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:

Innanzitutto un VCS protegge gli sviluppatori da se stessi e gli uni dagli altri - se non avesse altro scopo se non quello di 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 un team in cui il precedente giorni di lavoro è stato sovrascritto da un po 'di copia imprudente).

In secondo luogo fornisce una traccia 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à necessario dopo tutti.

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 motivi di discussione è abbastanza vicino). Se si è eseguito correttamente il backup del repository, è necessario proteggere gli asset dell'azienda.

Queste tre cose dovrebbero essere "esso" per la vendita di VCS - se un manager non riesce a vedere un valore sufficiente nel tempo sopra indicato per trovare un altro manager.

Una volta che hai venduto VCS (che, dopotutto, sono utili solo ai team di sviluppo in cui il numero di sviluppatori è maggiore di zero), allora la domanda sul perché DVCS su, diciamo, SVN o TFS e l'ulteriore domanda se lavorare internamente o utilizzare un servizio ospitato come Kiln o Bitbucket o Github (che fa privato se si paga) è piuttosto più profondo e più dipendente dal contesto.

VCS

Spiega semplicemente il concetto di backup . I backup ti consentono di vedere su cosa stavi lavorando in un determinato momento. Spiega come prima i programmatori VCS erano soliti copiare i loro interi progetti in modo compulsivo, generalmente per salvare ogni rilascio valido e stabile che avevano, quindi quando le cose andavano male avevano un buon punto di riferimento su quando le cose funzionavano, confrontale con le ultime cose e vedi dove loro o qualcun altro hanno incasinato e risolto il problema semplicemente osservando le differenze anziché gli interi due backup del progetto.

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

DVCSs

Per quanto riguarda il controllo della versione distribuita, spiega in che modo il controllo della versione tipica richiedeva un server e una connessione a Internet e che tutti si sono stancati di questo perché era più lento e tutti hanno lavorato su un singolo backup, se uno ha 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 fa pasticci con il proprio backup mentre lavorano e possono preoccuparsi di condividere il proprio lavoro in seguito quando hanno finito.

Un altro aspetto positivo è che, diversamente da un VCS centralizzato in cui esiste un solo backup, se la macchina con il backup prende fuoco, ci sono ancora altri backup completi da eseguire (almeno uno per ogni sviluppatore).

In sintesi : i DVCS ti consentono di lavorare nel tuo backup senza che tutti debbano essere stipati in un singolo server a disturbarsi a vicenda e ti preoccupano delle modifiche degli altri dopo che hai finito con le tue cose. Inoltre, non succede 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 il controllo della versione, è la possibilità di annullare e gestire il codice / la documentazione / qualunque cosa e semplificare la collaborazione con altri sviluppatori / scrittori / ecc ...

Questo è un buon punto di forza - ed è stato il motivo principale per cui ho usato un VCS per tutto il mio lavoro, oltre agli altri vantaggi: avere una storia, un repository di cui è possibile eseguire facilmente il backup ...

Alla maggior parte di loro piace l'idea e la trovano abbastanza utile, adottandola per i loro progetti (specialmente se comportano la collaborazione con altri ingegneri).

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

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

Se al momento non si utilizza il controllo versione, il team di sviluppo sta risolvendo i problemi risolti manualmente dal controllo versione. Tutti questi problemi sono stati ben elencati da altre risposte, quindi non entrerò qui.

Quello che devi fare è spiegare al tuo project manager che il team sta trascorrendo il Xnumero di ore ogni settimana risolvendo manualmente i problemi che GIT potrebbe risolvere automaticamente o, per esempio, nel 0.1 * Xnumero di ore degli sviluppatori.

Non affrontarlo usando le ragioni per cui GIT renderà la tua vita più facile o quella dei tuoi colleghi sviluppatori più facile, affrontala dal punto di vista del fatto che GIT spedirà il software in modo più rapido ed economico.

Mi piace la descrizione di @ Buttons840 come un pulsante Annulla per la base di codice. Potrebbe anche aiutare a confrontarlo con una versione (meno frustrante) di Word o la funzionalità "Traccia modifiche" di InDesign. Nella mia esperienza, riduce decisamente la necessità che una persona vada in giro dicendo 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. Ho nascosto 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 fare in modo che altri codici compensino il bug.

Se non si utilizza il controllo versione, come si fa a ricostruire l'ambiente di produzione?

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

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

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

Ciò semplifica il rilevamento di un problema dovuto a una build non valida (prod non corrisponde al controllo della versione) o a un bug di progettazione o di codifica (prod non corrisponde al controllo della versione).

Il controllo della versione semplifica l'assegnazione di un numero di versione a ciascun ambiente di test e ci si aspetterebbe naturalmente che la produzione abbia un numero di versione inferiore rispetto al test o allo sviluppo e che il test abbia un numero di versione inferiore rispetto allo sviluppo. In caso contrario, parte del codice non è stata testata correttamente.

Inoltre, se rilasci software la seguente funzione di un VCS è piuttosto essenziale: supponi che il tuo cliente trovi un bug. L'attuale sviluppo del software è probabilmente in uno stato molto diverso rispetto alla versione che ha il cliente. Forse il bug è stato risolto ora, forse non lo è, ma in ogni caso il software attuale non è in uno stato in cui puoi semplicemente spedirlo al cliente.

Un VCS rende banale tornare alla versione che è stata spedita al cliente, correggere il bug che stava richiedendo, costruirlo e spedirlo in una versione rivista. Tutto questo senza disturbare lo sviluppo attuale, senza dovergli consegnare una versione con caratteristiche incompiute / instabili o bug aggiuntivi introdotti a causa del nuovo sviluppo incompiuto.

Inoltre un VCS semplifica il porting di questa correzione nel nuovo ramo di sviluppo se il bug è ancora presente anche lì.

Con una forte disciplina puoi probabilmente gestirlo senza un VCS per un team molto piccolo, ma usarne uno 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, allora probabilmente hai un documento Word o un documento Excel che si trova da qualche parte che è modificato da più persone. E a volte quelle persone fanno copie locali, da portare in viaggio d'affari, ecc. O il documento viene spedito via e-mail dopo ogni modifica.

Se si dispone di un tale file, le modifiche di alcune persone sono state perse in passato o andranno perse in futuro. O la gente pensa di aver perso i 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 si scelgono software / librerie open source, avere un repository DVCS è sicuramente un vantaggio nei criteri di selezione.

1) Possiamo clonare l'intero repository, non dobbiamo preoccuparci del progetto o il suo sito Web è morto.

2) Le persone sono più disposte a inviare una correzione degli errori tramite richiesta pull, per una soluzione più rapida degli errori per problemi urgenti.