Ho davvero bisogno del controllo della versione?

Ho letto su Internet (vari siti e blog) sul controllo della versione. Quanto è bello e come tutti gli sviluppatori hanno bisogno di usarlo perché è molto utile.

Ecco la domanda: ne ho davvero bisogno? Sono uno sviluppatore front-end (di solito solo HTML / CSS / JavaScript) e NON ho mai avuto problemi come “Wow, i miei file di ieri!”. Ho provato ad usarlo, ho installato Subversion e TortoiseSVN , ho capito il concetto dietro il controllo della versione ma … Non posso usarlo (strano per me).

OK, quindi … è così male? Di solito lavoro da solo (libero professionista) e non avevo clienti che mi chiedessero di usare Subversion (ma non è mai troppo tardi per questo, giusto?). Quindi, dovrei iniziare e faticare a imparare a usare Subversion (o qualcosa di simile?) O è solo una perdita di tempo?


Domanda correlata: Buone scuse NON usare il controllo di versione .

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 una modifica ambiziosa sul sito web. Ti ci vorranno un paio di settimane e dovrai apportare modifiche a molte pagine. Tu vai al lavoro.

Il 50% ha terminato questa attività quando il cliente chiama e ti dice di abbandonare ciò che stai facendo per apportare modifiche urgenti ma minori al sito. Non hai finito con l’attività più grande, quindi non è pronto per andare in diretta, e il client non può aspettare la modifica più piccola. Ma vuole anche che il piccolo cambiamento venga fuso nel tuo lavoro per il resto.

Forse stai lavorando sull’attività di grandi dimensioni in una cartella separata contenente una copia del sito web. Ora devi capire come fare il piccolo cambiamento in un modo che possa essere implementato rapidamente. Lavori furiosamente e lo fai. Il client richiama con ulteriori richieste di perfezionamento. Lo fai anche tu e dispiegalo. Tutto bene.

Ora devi unirlo ai lavori in corso per il grande cambiamento. Cosa hai cambiato per il lavoro urgente? Stavi lavorando troppo velocemente per tenere appunti. E non puoi semplicemente diffare facilmente le due directory ora che entrambe hanno delle modifiche rispetto alla linea base da cui hai iniziato.

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

  • È ansible utilizzare le filiali per lavorare su attività a lungo termine e quindi unire nuovamente il ramo nella riga principale al termine.
  • Puoi confrontare interi gruppi di file con altri rami o con revisioni passate per vedere cosa è diverso.
  • È ansible tenere traccia del lavoro nel tempo (il che è ottimo per la segnalazione e la fatturazione).
  • È ansible ripristinare qualsiasi revisione di qualsiasi file in base alla data o a una pietra miliare definita.

Per il lavoro da solista, è raccomandato Subversion o Git. Chiunque è libero di preferire l’uno o l’altro, ma o è chiaramente migliore di non usare alcun controllo di versione. I buoni libri sono ” Pragmatic Version Control usando Subversion, 2nd Edition ” di Mike Mason o ” Pragmatic Version Control Using Git ” di Travis Swicegood.

Ci sono molti vantaggi, sì, ne hai bisogno.

  • Quali strumenti / tecniche possono essere utili a uno sviluppatore solista?
  • Miglior controllo della versione per sviluppatore solitario

Non hai bisogno del controllo della versione più di quanto un artista trapese abbia bisogno di una rete di sicurezza. È come fare il backup del tuo disco rigido – la maggior parte delle volte sembra ridondante perché non succede nulla, ma alla fine sarà necessario. Non ci sono maybes qui. Accadrà. E non puoi mai prevedere quando e il passato sono un indicatore scarso di quando accadrà. Può succedere solo una volta in futuro, ma anche se sai che accadrà quando non saprai quanto sarà male.

Sì!

Fallo. Non ti farà male ..

Di solito passo da un laptop a un PC e viceversa ed è assolutamente fantastico avere il codice da qualche parte in un repository centrale.

A volte è bello andare a tornare all’ultima revisione perché hai rovinato qualcosa che sarebbe stato troppo difficile da risolvere ..

Il più grande vantaggio che manca è la possibilità di riprodurre il codice sorgente che ha generato una vecchia build.

Al momento della compilazione, taggate il controllo del codice sorgente con ‘Build 4.26’. Il giorno dopo si inizia a programmare la build 4.27. Tre mesi dopo, quando un cliente dice “Sto usando la build 4.26 e c’è un bug nella funzionalità Frickershaw, non posso eseguire l’aggiornamento a nessun’altra build a causa di alcune modifiche ai formati di file creati nella build 4.27. tutto quello che puoi fare per me? Sono disposto a pagare. ”

Quindi, è ansible eseguire il checkout di un ramo del codice sorgente 4.26 … correggere la funzione Frickershaw e quindi ribuild il pacchetto per l’utente in circa un’ora o due. Quindi puoi tornare alla versione 4.39 e continuare a lavorare.

Allo stesso modo, è ansible rintracciare il punto esatto in cui è stato aggiunto un errore. Prova le versioni 4.25 per il bug, poi 4.20, poi 4.10 e infine scopri che il bug è stato introdotto nella versione 4.12. Quindi cerchi tutte le modifiche apportate tra “Build 4.11” e “Build 4.12”, quindi concentrati sulla funzione Frickershaw. È ansible trovare rapidamente il codice sorgente per il bug senza mai eseguirne il debug.

Branching non ti sembra utile? Non hai mai voluto provare qualcosa per vedere se avrebbe funzionato? Anch’io faccio un sacco di semplici html / css, e lo trovo inestimabile. Non c’è letteralmente alcun pericolo nella ramificazione per testare qualcosa, vedere se funziona, e decidere “meh” e poi tornare indietro.

Non ho mai avuto bisogno di ottenere un backup (knock on wood), ma trovo inestimabile solo la funzionalità di rollback.

Alcuni vantaggi come libero professionista:

  • Conoscere in modo definitivo cosa si è modificato in ogni singolo file e quando (purché si verifichi spesso)
  • Rollback a qualsiasi versione del tuo passato. Sorprendente quanto spesso questo è prezioso.
  • Tieni traccia di una serie di modifiche come “rilascio”. In questo modo sai cosa sta attualmente utilizzando ciascun client e cosa è in sviluppo.
  • di riserva
  • La possibilità di condividere facilmente un progetto se improvvisamente non sei da solo

Prova un DVCS come Git o Bazaar . Sono incredibilmente facili da configurare, facili da usare e offrono tutte le funzionalità importanti di Subversion, CVS, ecc.

La chiave è che è ansible tornare a una versione funzionante quando si interrompe qualcosa, che è spesso molto più veloce di annullare manualmente la modifica.

Non assumerei un imprenditore senza che si integrasse nei nostri processi. Dovrebbero accedere al codice tramite il nostro SVN ed è improbabile che vengano pagati senza incontrare i test di unità e i requisiti di revisione del codice.

In caso di contratti, mi assicurerei di avere una solida esperienza in entrambi i modelli di VSS (check-in / out) e CVS (fusione e conflitto).

Lavorando da solo hai una big opportunità per giocare e imparare con le ultime – proverei Git.

Come sviluppatore solitario, puoi pensare al controllo del codice sorgente come un annullamento illimitato, che funziona attraverso sessioni e riavvii.

Un piccolo vantaggio del controllo del codice sorgente per me è che lavoro su più computer di sviluppo. È facile spostare il mio lavoro tra le macchine.

Il più grande vantaggio a mio parere è già stato elencato. Mi permette di dormire la notte sapendo che se dovessimo annullare un cambiamento sarà abbastanza facile.

Penso che il vantaggio principale nel passare da un “sistema di file keep-all-versions” a un sistema di controllo del codice sorgente risieda nel fatto che lo sccs aggiunge struttura a tutte quelle versioni che hai tenuto di tutti quei file e ti fornisce registri di “quale era lo stato coerente dell’intero file system al punto X”.

In altre parole, “Quale versione del file A va con quali versioni di B, C, D, …”.

E un ripensamento (¡!): L’atto speciale del commit o del check-in ti fa pensare a “cos’è questo?”, E il messaggio di log risultante può, si spera, servire da memoria …

La risposta letterale a questa domanda è: No, non hai BISOGNO del controllo della versione.

Si, tuttavia, si desidera il controllo della versione, anche se non lo si conosce.


Detto questo, molti strumenti SCM possono essere misteriosi o addirittura spiacevoli da usare fino a sfondare la Barriera di Grok, quindi rivediamolo un po ‘:

“Tuttavia, si desidera il controllo della versione FACILE DA USARE”. Ed è là fuori … scarica un gruppo di client visivi consigliati e dai loro un giro rapido, quindi prova le mappe migliori nel modo in cui pensi.

Il che porta alla domanda che intendevi porre:

Perché voglio utilizzare il controllo della versione? ”

Risposta: il controllo della versione ti consente di essere INNANZITUTTO!

Sì, ne hai bisogno.

Per lo meno, per un singolo negozio sviluppatore, è necessario spostare il codice in una directory Nome progetto-Data-ora più volte al giorno.

Cioè, scrivi uno script che eseguirà automaticamente il backup della directory di lavoro a pranzo e al momento dell’abbandono, senza sovrascrivere altri backup.

Questo può crescere abbastanza velocemente, quindi alla fine vorrai salvare solo le differenze tra i file, che è ciò che fa un’applicazione VC.

Dato che di solito lavori da solo, direi che è una buona idea usare il controllo della versione. Uno dei principali vantaggi che ho riscontrato nell’utilizzo del controllo della versione (Subversion nel mio caso) è che quando si lavora da solo mi dà più fiducia nel provare un nuovo approccio al problema. Puoi sempre dirigerti verso un nuovo metodo o framework per risolvere il problema e vedere se ti piace di più. Se si scopre che questo ramo non funziona, puoi semplicemente abbandonarlo e tornare al vecchio metodo. Questo rende anche più facile provare le diverse soluzioni fianco a fianco.

Quindi, se hai mai visto un approccio diverso alla risoluzione di un problema e volevi provarlo, utilizzerei sicuramente il controllo della versione come strumento per semplificare la procedura.

Se si sta lavorando da soli e si stanno eseguendo backup su base regolare, VC potrebbe non essere necessario (a meno che non si contino i backup come cronologia delle versioni). Non appena inizi a lavorare con un altro sviluppatore, dovresti ottenere il controllo della versione sul posto in modo che non inizi a sovrascrivere il lavoro a vicenda.

Anche se non ne hai bisogno in questo momento, è qualcosa di cui avrai bisogno ogni volta che lavori in una squadra.

Avere una cronologia delle modifiche al tuo html / css / javascript può essere una manna dal cielo. Essere in grado di confrontare il tuo front-end con il codice un mese o diversi mesi fa può davvero fare molto per capire perché improvvisamente il modello è tutto di nuovo.

Inoltre, se desideri / hai bisogno di ricevere assistenza sui tuoi progetti, avrai un sistema semplice per distribuire, tenere traccia e distribuire contenuti aggiornati.

Sicuramente fallo, ti ringrazierai una volta che ti sarai abituato.

Pagamento (una volta) Aggiornamento (inizio del giorno) Conferma (fine dell’attività / modifica dopo il test)

Questo è tutto ciò che c’è da fare. Non impegnare OGNI singola modifica che stai aggiornando nel browser, solo quella che vuoi pubblicare.

Pensa se ti piace un backup. È un po ‘irritante fino al giorno in cui ne hai bisogno. Quindi la quantità di lavoro che si perde è direttamente proporzionale alla frequenza dei backup.

Un altro vantaggio è quello di essere in grado di guardare ai vecchi modi in cui hai fatto cose che potrebbero essere diventate obsolete in un determinato punto, ma potrebbero essere utili in un altro. Basta tagliare e incollare il vecchio codice che hai ottenuto quando fai un confronto.

A meno che non ti piaccia reinventare la ruota che hai già reinventato …

Quando le cose possono andare storte lo faranno. È molto utile avere la possibilità di fare riferimento al codice che potresti aver cancellato un mese fa, o di ripristinare l’intero progetto dopo un guasto o un aggiornamento dell’hardware.

Potrebbe anche esserci un punto in futuro quando il progetto è lavorato più di te. La capacità di prevenire (o controllare) la ramificazione e il controllo delle versioni è un must in un ambiente del genere.

Deve deve deve deve deve. È necessario utilizzare il controllo della versione.

Questo è della massima importanza.

Se non capisci perché ora, lo farai un giorno.

Quando il tuo cliente telefona in preda al panico perché qualcosa è rotto sul sito live ed è una regressione, sarai felice di poter aprire TortoiseSVN e vedere cosa è stato fatto martedì scorso a causare la rottura.

È davvero strano Da quando ho iniziato a utilizzare il controllo delle versioni, ho avuto occasionalmente la necessità di cercare vecchie copie del mio codice e usarle. Non ho mai avuto bisogno di farlo prima … probabilmente perché l’idea di fare non è stata davvero valida. È facile non notare quelle volte in cui potresti aver trovato utile il controllo della versione.

Cerca all’interno di un’intera base di codice. È una caratteristica killer, soprattutto perché la ricerca viene triggersta su un’altra macchina in modo da poter continuare indisturbato il lavoro.

Per inciso, è la ragione per cui non siamo passati a SourceGear Vault. Non può farlo. Stiamo ancora cercando una sostituzione compatibile con SourceSafe per … beh, SourceSafe. Nonostante quello che dicono tutti, non ci ha deluso ancora *

* questa potrebbe essere solo una questione di tempo.

Penso che tu abbia preso la decisione giusta per usare un qualche tipo di controllo di versione. Per semplicità, mi piacerebbe andare con SVN (ignora CVS come SVN è fondamentalmente un CVS “migliore”)

SVN può funzionare con repository “locali” direttamente sul filesystem e su molte piattaforms in modo da non dover mordere troppo nell’infrastruttura (server, reti, ecc.)

Grande risorsa per SVN: http://svnbook.red-bean.com

Non ne so molto di GIT, ma essendo open source e guadagno un sacco di mindshare probabilmente ha molti vantaggi simili!

Prendendo in prestito una citazione da qualche parte: potresti non averne bisogno ora, ma quando lo farai, sarai felice di averlo fatto.

Buona versione!

Sebbene vecchi e grezzi, abbiamo trovato che Microsoft Visual SourceSafe funziona. Funziona benissimo per mantenere la cronologia delle versioni. Se non sei preoccupato per la ramificazione, che potresti non essere lo sviluppatore solista, potrebbe essere sufficiente.

Per quanto riguarda il check-in, trovare un buon checkpoint può essere una sfida, ma il check-in su ogni salvataggio renderà difficile il tracciamento delle versioni.

“Ho davvero bisogno del controllo della versione?”

Sì. A meno che non scrivi un codice perfetto che non ha mai bisogno di essere cambiato.

Un esempio: avevo un requisito. Ho creato una pagina web, ho trascorso circa un giorno sulla pagina, la compatibilità con la Sezione 508 (era circa 6-7 anni fa) e caricata sul sito web. Successivamente il requisito è stato cambiato drasticamente. Trascorro un altro giorno a lavorare sulla pagina (e i file di Hayuge Excel non si convertono facilmente in HTML accessibile). Circa una settimana dopo, gli switch client chiedono che torniamo alla versione A. Il controllo del codice avrebbe fatto ciò in circa 10 minuti. Com’era, dovevo soffiare un altro% $ # ^^ e $ # giorno sull’attività.

Sì, è necessario il controllo della versione per scopi di sviluppo o semplicemente per la memorizzazione dei documenti. In questo modo, puoi tornare indietro nel tempo se ti viene richiesto di fare ciò per annullare le modifiche o l’errore fatto su un codice o documenti.

Una volta che si inizia a lavorare su un team che fa riferimento all’aggiornamento di “componenti” da più chiamanti / applicazioni, il controllo della versione sarà assolutamente necessario. In quell’ambiente, non c’è modo di tenere il passo con tutte le permutazioni di un ansible cambiamento.

Hai bisogno del controllo della versione proprio come hai bisogno di assicurazione nella vita.

È necessario il controllo della versione per gestire diverse versioni di file. Con esso, puoi ottenere e lavorare sui file da diversi luoghi e consente ai membri del team di collaborare allo stesso progetto.