Perché dovrei usare il controllo della versione? [chiuso]

Stavo leggendo un blog in cui lo scrittore ha detto questo

"Il codice non esiste a meno che non sia archiviato in un sistema di controllo della versione. Usa il controllo della versione per tutto ciò che fai. Qualsiasi controllo della versione, SVN, Git, persino CVS, masterizzalo e usalo."

Non ho mai usato alcun tipo di controllo della versione e non lo trovo così eccezionale. L'ho cercato su Google e l'ho esaminato prima, ma ho solo bisogno che sia messo in termini di bambini se vuoi per favore.

A quanto ho capito in questo momento, cose come SVN servono per memorizzare il tuo codice online per un gruppo di utenti o altri sviluppatori per avere accesso allo stesso codice. Una volta aggiornato un codice, puoi inviare la nuova versione e SVN manterrà le copie del vecchio codice e di quelle nuove che aggiorni.

È questa l'idea di base o mi sto sbagliando completamente?

Se ho ragione, potrebbe non essere molto utile se io:

• Non avere altre persone che lavorano sul codice.
• Non pianificare di lasciare che altri abbiano il codice.

Hai mai:

• Hai fatto una modifica al codice, hai capito che era un errore e volevi tornare indietro?
• Hai perso il codice o avevi un backup troppo vecchio?
• Hai dovuto mantenere più versioni di un prodotto?
• Volevi vedere la differenza tra due (o più) versioni del tuo codice?
• Volevi dimostrare che una particolare modifica ha rotto o corretto un pezzo di codice?
• Volevi rivedere la cronologia di un codice?
• Volevi inviare una modifica al codice di qualcun altro?
• Volevi condividere il tuo codice o consentire ad altre persone di lavorare sul tuo codice?
• Volevi vedere quanto lavoro viene svolto e dove, quando e da chi?
• Volevi sperimentare una nuova funzionalità senza interferire con il codice funzionante?

In questi casi, e senza dubbio in altri, un sistema di controllo della versione dovrebbe semplificarti la vita.

Citare erroneamente un amico: uno strumento civilizzato per un'epoca civile.

Anche se lavori da solo puoi trarre vantaggio dal controllo del codice sorgente. Tra gli altri, per questi motivi:

• Non perdi niente. Non ho mai più commentato il codice. Lo elimino semplicemente. Non ingombra il mio schermo e non è perso. Posso recuperarlo controllando un vecchio commit.

• Puoi sperimentare a piacimento. Se non risolve il problema, ripristinalo.

• Puoi guardare le versioni precedenti del codice per scoprire quando e dove sono stati introdotti i bug. git bisectè fantastico in questo senso.

• Funzionalità più "avanzate" come la ramificazione e l'unione consentono di avere più linee parallele di sviluppo. Puoi lavorare in due funzioni simultanee senza interferenze e passare avanti e indietro senza troppi problemi.

• Puoi vedere "cosa è cambiato". Può sembrare semplice, ma è qualcosa che mi ritrovo a controllare molto. Molto spesso inizio il mio flusso di lavoro individuale con: cosa ho fatto ieri?

Vai avanti e provalo. Inizia lentamente con le funzionalità di base e impara altre man mano che procedi. Presto scoprirai che non vorrai mai tornare al "periodo oscuro" di nessun VCS.

Se vuoi un VCS locale puoi configurare il tuo server subversion (cosa ho fatto in passato), ma oggi ti consiglio di usare git. Molto più semplice. Semplicemente cdnella directory del codice ed esegui:

git init

Benvenuto nel club.

Il controllo della versione è uno strumento raro che direi assolutamente necessario, anche se lo stai usando solo come sviluppatore singolo. Alcune persone dicono che è uno strumento con cui vivi e muori, sono d'accordo con questa affermazione.

Probabilmente usi il controllo della versione in questo momento, anche se non lo conosci. Hai delle cartelle che dicono "XXX Php Code (dicembre)" o "XXX.php.bak.2"? Queste sono già forme di controllo della versione. Un buon sistema di controllo della versione si prenderà cura di questo per te automaticamente. Sarai in grado di eseguire il rollback in qualsiasi momento (in cui i dati sono archiviati) ed essere in grado di vedere una copia esatta di tali dati.

Inoltre, se adotti un sistema come subversion e utilizzi un repository remoto (come uno su un server di tua proprietà), avrai un posto dove conservare tutto il tuo codice. Hai bisogno di una copia del tuo codice da qualche altra parte? Nessun problema, dai un'occhiata. Arresto anomalo del disco rigido a casa? Nessun problema (almeno con il tuo codice sorgente).

Anche se non usi il controllo della versione ora, probabilmente lo userai in un momento successivo della tua carriera e potresti trarre vantaggio dal diventare più a tuo agio con i principi ora.

Anche lavorando da solo, è mai successo? Esegui la tua app e qualcosa non funziona e dici "che ha funzionato ieri, e giuro che non ho toccato quella classe / metodo". Se verifichi regolarmente il codice, un diff veloce della versione mostrerà esattamente cosa è cambiato nell'ultimo giorno.

Ecco uno scenario che può illustrare l'utilità del controllo del codice sorgente anche se lavori da solo.

Il tuo cliente ti chiede di implementare un'ambiziosa modifica al sito web. Ci vorranno un paio di settimane e comporterà modifiche a molte pagine. Ti metti al lavoro.

Hai terminato al 50% questa attività quando il client chiama e ti dice di abbandonare ciò che stai facendo per apportare una modifica urgente ma più piccola al sito. Non hai finito con il compito più grande, quindi non è pronto per andare in diretta e il cliente non può aspettare il cambiamento più piccolo. Ma vuole anche che la modifica minore venga incorporata nel tuo lavoro per una modifica più ampia.

Forse stai lavorando su un'attività di grandi dimensioni in una cartella separata contenente una copia del sito web. Ora devi capire come fare la piccola modifica in un modo che possa essere implementato rapidamente. Lavori furiosamente e lo porti a termine. Il cliente richiama con ulteriori richieste di perfezionamento. Fai anche questo e distribuiscilo. Tutto bene.

Ora devi unirlo al lavoro in corso per il grande cambiamento. Cosa hai cambiato per il lavoro urgente? Lavoravi troppo velocemente per prendere appunti. E non puoi semplicemente diffondere facilmente le due directory ora che entrambe hanno modifiche rispetto alla linea di base da cui sei partito.

Lo scenario precedente mostra che il controllo del codice sorgente può essere un ottimo strumento, anche se lavori da solo.

• Puoi usare i rami per lavorare su attività a lungo termine e poi unire il ramo di nuovo nella linea principale quando ha finito.
• Puoi confrontare interi set di file con altri rami o con revisioni passate per vedere cosa c'è di diverso.
• Puoi tenere traccia del lavoro nel tempo (il che è ottimo per la reportistica e la fatturazione tra l'altro).
• È possibile ripristinare qualsiasi revisione di qualsiasi file in base alla data o a una pietra miliare definita.

Per il lavoro da solista, si consiglia Subversion o Git. Chiunque è libero di preferire l'uno o l'altro, ma è chiaramente meglio che non utilizzare alcun controllo di versione. Buoni libri sono " Pragmatic Version Control using Subversion, 2nd Edition " di Mike Mason o " Pragmatic Version Control using Git " di Travis Swicegood.

Autore originale: Bill Karwin

Anche come un unico controllo del codice sorgente per sviluppatori offre un grande vantaggio. Ti consente di memorizzare la cronologia del tuo codice e tornare alle versioni precedenti del tuo software in qualsiasi momento. Ciò ti consente una flessibilità senza paura di sperimentare perché puoi sempre ripristinare un'altra versione del tuo codice sorgente che funzionava.

È come avere un gigantesco pulsante "Annulla" fino alla prima riga di codice.

È quasi impossibile vivere senza il controllo della versione dopo aver iniziato a usarlo. È indispensabile se più di uno sviluppatore lavora sulla stessa base di codice ... ma è anche abbastanza utile per un singolo sviluppatore.

Tiene traccia delle modifiche nel codice e ti consente di tornare alle versioni precedenti. Ti libera di sperimentare con la consapevolezza che se qualcosa si rompe puoi annullare le modifiche.

Ottieni sicurezza (nel senso di avere un backup del tuo codice) e controllo delle versioni del tuo codice (supponendo che tu abbia l'abitudine di eseguire spesso le modifiche). Entrambe sono cose molto buone anche se nessun altro finisce mai per lavorare sul codice con te ...

Il controllo della versione è ottimo per controllare le versioni precedenti, anche se lavori da solo. Ad esempio, se elimini accidentalmente un codice o un file, puoi recuperarlo; oppure puoi confrontare le versioni precedenti per vedere perché si è insinuato un nuovo bug. Va bene anche se sei una persona che lavora in più posizioni.

Il mio preferito è git.

Esistono diversi motivi per utilizzare il controllo della versione, anche se sei l'unica persona che toccherà il codice.

• Backup : cosa succede se il tuo disco rigido si blocca? Hai una copia da qualche parte?
• Cronologia delle revisioni : al momento conservi copie del codice in cartelle diverse? Il controllo della versione ti dà la possibilità di tenere traccia delle modifiche nel tempo e diffondere facilmente diverse revisioni, unire, ripristinare le modifiche, ecc. Utilizzando gli strumenti.
• Rami : la capacità di testare alcune modifiche, tenere traccia di ciò che si sta facendo e quindi decidere se mantenerlo o meno e unirlo al progetto principale o semplicemente buttarlo via.

Se mantieni il tuo codice sotto il controllo della versione, sarà davvero facile vedere quali file hai modificato (o hai dimenticato di aggiungere alla baseline).

Qualcosa che nessun altro sembra aver menzionato esplicitamente è l'etichettatura o l'etichettatura delle pubblicazioni. Se hai un client che utilizza la versione 1 del tuo software e sei impegnato a lavorare sulla versione 2, cosa fai quando il client segnala un bug e devi creare la versione 1.1?

Un sistema di controllo del codice sorgente ti consentirà di etichettare ogni versione che fai in modo da poterla tornare in un secondo momento, apportare la correzione (e unire quella correzione nel codice della nuova versione 2) e creare una nuova versione senza preoccuparti di poter fornire accidentalmente qualcosa che non è pronto.

Il controllo del codice sorgente è una parte fondamentale dello sviluppo del software moderno. Se non lo usi (anche per progetti personali, più esperienza hai, meglio è) stai facendo qualcosa di sbagliato.

Di solito una delle prime domande che pongo quando vengo intervistato per un lavoro è "Cosa usi per il controllo del codice sorgente?" Finora solo un posto ha detto "Niente" ma stavano progettando di aggiustare quel "Real presto ora ..."

Il fatto che altri sviluppatori partecipino o meno è totalmente ortogonale alla necessità di un sistema di controllo delle versioni.

Puoi essere l'unico sviluppatore ma trarrai comunque vantaggio da:

• una traccia storica di tutte le tue modifiche
• capacità di andare avanti e indietro su quella storia
• capacità di sperimentare con il sorgente e pur avendo una versione funzionante (branching)
• una copia di backup (soprattutto se si utilizza una macchina diversa come server di controllo del codice sorgente e ancora di più se viene eseguito regolarmente il backup di quella macchina)

Ora, se hai un gruppo che sviluppa sulla stessa base di codice, il controllo della versione è ancora più necessario

• le persone possono modificare lo stesso file contemporaneamente (a seconda del particolare sistema, ma la maggior parte delle persone sane ti consente di farlo)
• puoi dire chi ha fatto cosa al codice quando

Quando sono coinvolte più persone, è più rilevante quale strumento di controllo della versione scegli, a seconda dello stile di sviluppo.

Si tratta anche di eseguire il backup di vecchi file, ecco perché si chiama "Subversion". Quindi puoi gestire più versioni del tuo lavoro in cui puoi tornare indietro (ripristinare) e gestirne la diversa implementazione (ramificazione).

Potresti scoprire di avere una versione funzionante del tuo programma.

Decidi di aggiungere alcune nuove funzionalità per un periodo di tempo e le rilasci.

Inizi a ricevere segnalazioni di bug che interessano un codice che pensavi di non aver toccato.

Usando SVN, ad esempio, puoi tornare a una versione precedente e verificare se il nuovo bug esiste. Una volta trovata una versione che ha introdotto il bug, sarà più facile risolverlo poiché puoi confrontare la versione che ha funzionato con quella che non ha funzionato e vedere cosa è cambiato, quindi restringerà la ricerca.

Il controllo del codice sorgente ha molti usi, anche se sei l'unico sviluppatore.

Sembra che tu stia cercando qualcosa di un po 'più leggero. Dai un'occhiata a Mercurial ( fantastico libro di consultazione ). Lo uso per tutto, dal codice sorgente alla corrispondenza personale.

Alcuni vantaggi:

• Pulsante Annulla gigante, in modo da poter restituire quei giorni felici della scorsa settimana in cui il codice è stato effettivamente eseguito
• Codice usa e getta. Non sei sicuro che questo sia il modo migliore per fare qualcosa? Crea un ramo e sperimenta. Nessuno, tranne te, deve saperlo se stai usando un DVCS come Mercurial.
• Sviluppo sincronizzato. Sviluppo su 4 computer diversi. Spingo e tiro tra di loro per mantenere la corrente, quindi non importa quale sia, ho le versioni più recenti.

Anche se non ti sei ancora trovato in una situazione in cui hai bisogno di una versione precedente del tuo programma, avere un controllo del codice sorgente ti dà maggiore sicurezza per apportare modifiche importanti.

Mi sono ritrovato a fare un refactoring più aggressivo dopo aver usato il controllo del codice sorgente perché sapevo sempre che una versione funzionante poteva essere facilmente ripristinata.

Inoltre, solo di recente ho iniziato a interessarmi al controllo della versione. Nei sistemi di controllo della versione, hai il concetto di un repository per il tuo codice. Una vasta gamma di nuovi comandi della shell vengono appresi molto rapidamente in modo da poter interagire con questo repository.

Dopo aver salvato il codice in un file, puoi inviarlo al repository del tuo progetto. Man mano che sviluppi il codice e effettui il commit delle modifiche, il repository sviluppa una serie di revisioni . È possibile accedere a uno qualsiasi di questi controllando una revisione. Se lavori da solo, è improbabile che farai molti controlli a meno che non perdi i file di codice o desideri lavorare su una macchina diversa. In questi casi, di solito controllerai l'ultima revisione di tutti i file.

Da parte mia, non conservo più file o cartelle denominati "project_old" quando decido di eseguire il refactoring di qualcosa. Tutte le modifiche apportate vengono memorizzate in modo incrementale e sarò sempre in grado di tornare indietro a un progetto che ha funzionato nel suo complesso. Uso raramente l'FTP per eseguire il deploy ora perché devo solo controllare il mio codice tramite ssh. Vengono scaricati solo i file che ho modificato e se devo ricaricare sul server il terminale è già lì.

Ho trovato questo discorso su GIT davvero istruttivo; http://www.youtube.com/watch?v=4XpnKHJAok8

È un Google Talk in cui Linus Torvalds argomenta a favore dell'utilizzo di un sistema di controllo della versione rispetto a un altro. In tal modo spiega come funzionano utilizzando i concetti e poi confronta diversi modi di implementarli.

Probabilmente vorrai qualcosa come sovversione anche se lavori da solo in modo da avere una cronologia di tutte le tue modifiche. Potresti voler vedere come appariva un pezzo di codice una volta per ricordare perché hai fatto una modifica.

Il controllo del codice sorgente è utile anche quando esegui spesso il check-in. Se esegui il check-in spesso, sarai sempre in grado di tornare indietro spesso. Molte volte potresti iniziare a percorrere una strada per risolvere un problema e poi renderti conto che era la strada sbagliata da percorrere. Molte volte potresti semplicemente continuare ad abbaiare sulla strada sbagliata e finire per costruire una soluzione terribile, solo perché non volevi perdere tutto il tuo lavoro. Effettuando spesso il check-in, l'ultimo punto di "felicità" non è lontano quindi anche se si imbocca la strada sbagliata si può sempre tornare indietro e riprovare e fare una soluzione più elegante e semplice. Che è sempre una buona cosa in modo da poter capire e mantenere ciò che hai scritto in futuro.

Dipende dalle dimensioni del progetto e dalla frequenza con cui cambi idea su parti di esso. Per piccoli progetti in cui stai solo facendo qualcosa in modo lineare, il controllo della versione probabilmente non sarà di grande aiuto (anche se se elimini o corrompi accidentalmente un file senza controllo della versione, piangerai).

Ma un paio di settimane fa ho incontrato un amico che stava scrivendo un enorme progetto di hobby da solo. Aveva dieci o venti copie del suo codice, con suffissi come "X1", "X2", "test", "più veloce" e così via.

Se hai creato più di due copie del codice, è necessario il controllo della versione . Un buon sistema di controllo della versione ti consente di annullare una modifica apportata qualche tempo fa senza annullare le cose che hai fatto dopo aver apportato quella modifica. Ti consente di vedere quando sono state apportate determinate modifiche. Ti permette di dividere il tuo codice in due "percorsi" (ad esempio uno per testare una nuova idea, l'altro per mantenere il tuo codice "provato e affidabile" al sicuro fino a quando non hai finito di testare) e poi unirli di nuovo insieme.

È il 2019. Sto incontrando obiezioni, in questa data relativamente tarda, all'utilizzo di Git; obiezioni che vedo sollevare qui. Questa discussione ha chiarito notevolmente l'imperativo di utilizzare il controllo del codice sorgente anziché semplicemente creare copie di backup con nome. Un punto chiave è l'uso del controllo del codice sorgente anche dove abbiamo progetti di sviluppatori singoli. Nessuno è perfetto. Fai degli errori. Se sei eccezionalmente bravo e intelligente svilupperai app più complesse; ma farai comunque degli errori e questo lo gestirà. Geez oh Pete! Non uso mai Linux ma credo che tutti rispettiamo la grande intelligenza tecnica di Linus Torvalds. Ha riconosciuto l'importanza del controllo del codice sorgente e ha dato un contributo fondamentale all'avvio di Git. Questo è un punto riassuntivo per tutte le ragioni qui fornite. Torvalds lo capisce: il controllo del codice sorgente è molto importante: utilizzare il controllo del codice sorgente. Grazie a tutti coloro che hanno commentato questo argomento di lunga data.