Controllo della versione per sviluppatori indipendenti?

Se usi il controllo del codice decentrato (Mercurial o Git o Bazaar o altro), ottieni vantaggi rispetto a SVN / CVS che lo rende facile, utile e potente da usare nel caso tu sia un indy:

1. Ti impegni a livello locale : la tua directory del progetto è il tuo repository con la cronologia COMPLETA. Quindi non devi avere un server, ti impegni direttamente nel repository e puoi avere diversi repository nello stesso computer. Usando un laptop che apri a volte per continuare a lavorare sulle tue cose? Grande! Non devi configurare un server e se ne hai bisogno uno in seguito, è semplice e devi solo "spingere" e "tirare" le modifiche tra i repository.
2. È fatto per facilitare la sperimentazione : spesso è necessario avere un'idea di una funzione senza codice inquinante. Con SVN e CVS puoi già utilizzare un sistema di diramazione e abbandonare il ramo se la funzionalità non è buona come volevi che fosse. Ma se vuoi unire la funzionalità con la versione trunk, avrai molte difficoltà a sistemare le sorprese. Git, Mercurial e Bazaar (almeno) rendono le fusioni e le diramazioni davvero facili. Puoi anche duplicare un repository, lavorarci sopra, crearlo e ucciderlo o inserire le modifiche nel repository principale, se lo desideri.
3. Flessibilità dell'organizzazione : come indicato in precedenza, poiché i repository che organizzi come ti servono, è facile iniziare da solo e consentire ad altre persone di lavorare con te cambiando la tua organizzazione. Nessuna organizzazione è imposto quindi devi solo configurarlo e voilà. Spesso spingo / sposto le modifiche tra i miei computer (laptop / desktop / server) e sono ancora da solo sui miei sviluppatori. Uso Mercurial e questo mi aiuta a duplicare il mio lavoro, ma anche a lavorare sulle funzionalità che ho pensato all'esterno sul mio laptop, quindi a continuare a lavorare su altre funzionalità sul mio desktop, quindi a trasferire le modifiche del laptop sul mio desktop o server e unire l'intero desktop + laptop e metterlo (come backup e repo di lavoro di squadra futuro) sul mio server.
4. Aiuta a configurare i backup : se imposti un repository centrale (su GitHub se è pubblico o in un repository privato su BitBucket) puoi facilmente scrivere uno script che verrà eseguito ogni volta che viene avviato un computer e quindi passare il suddetto script ai tuoi amici in modo che faccia regolarmente backup automatici del tuo lavoro. È quello che sto facendo quindi sono sicuro che non sarà facile perdere il lavoro.

In effetti, al momento, non ci sono scuse per non utilizzare uno strumento di controllo sorgente per alcun progetto. Perché sono più potenti e flessibili di prima e si adattano alle tue esigenze.

Il controllo del codice sorgente è assolutamente inutile per gli sviluppatori indipendenti, perché come tutti sappiamo:

• gli sviluppatori indipendenti non commettono errori
• gli sviluppatori indipendenti non eseguono mai revisioni che non funzionano
• gli sviluppatori indipendenti non hanno mai più di una versione, quindi non hanno alcun uso per i rami
• gli sviluppatori indipendenti non si preoccupano mai di cosa hanno modificato ieri o della scorsa settimana
• gli sviluppatori indipendenti non hanno mai e mai bisogno di backup

Chiamami uno "sviluppatore dipendente": i repository Mercurial clonano facilmente tra desktop, laptop, unità di backup USB e bitbucket.org. Sono diventato dipendente e mi piace così!

Perché no?

Sono uno sviluppatore solista e uso BitBucket e Mercurial per i miei progetti personali. Avere la possibilità di ripristinare e forgiare il codice è semplicemente troppo bello per passare.

Trovo valore in esso, personalmente. I miei progetti sono tutti controllati in repository git (che mantengo su più macchine in caso di guasto hardware). Le funzionalità più utili sono le ramificazioni (in modo che io possa eseguire un esperimento che mette in crisi metà del mio codice base, e non preoccuparsi di far saltare tutto in modo permanente) e di ripristinare (che in pratica è solo annullare su steroidi, nel caso trovassi che ne ho fatto un po ' errore che è fuori dal normale intervallo di annullamento).

Sì.

Anche i singoli sviluppatori devono a volte vedere lo stato del loro codice da una revisione precedente. Ed è sempre una buona idea fare il backup di tutto ciò che è importante, e questo vale per tutte le persone.

Sì. È molto, molto utile Il mio amico Matt Gallagher ha postato questo eccellente articolo su questo argomento molto pochi giorni fa al suo blog di sviluppo iOS / MacOS" Cocoa With Love ".

L'articolo è Mac & Git centric ma copre le basi.

Potresti anche essere interessato alle seguenti Domande StackExchange (e alle loro risposte).

• Ci sono vantaggi nell'utilizzo un dvcs per uno sviluppatore solista?
• Quali tecniche degli strumenti possono essere utili a uno sviluppatore solista?
• Git per uno sviluppatore solista.

Worth ?? Must! Se non usi il controllo del codice sorgente, non controlli le fonti, e questo è male. Non puoi diff non puoi ripristinare, non puoi tenere traccia delle modifiche - passerai ore a cercare di scoprire il bug fittizio che hai appena inserito. È meglio averlo su qualche server di backup, ma puoi anche usare il tuo computer e utilizzare qualsiasi metodo di backup che ritieni appropriato.

Utilizzare assolutamente il controllo del codice sorgente. Quindi configura un server di build e automatizza i processi di generazione e test. Trigger si basa sulla tua fonte di commit del tuo repository centrale. Ho lavorato da solo per tre anni in questo modo ed è meraviglioso.