Non sono sicuro di dover utilizzare un repository di codice quando sono l'unico a lavorare su un progetto.
Sì. Non si sa mai quando più persone potrebbero essere coinvolte nel progetto. Inoltre, i repository ti consentono di eseguire il rollback quando aggiungi per errore qualcosa che non funziona.
Potresti utilizzare git per il controllo della versione sulla tua macchina senza la necessità di un repo centralizzato. Tuttavia, fino a quando utilizzi git, potresti anche impostare un repository su GitHub . Ci vogliono solo pochi minuti se sei già lì. Se non sei su GitHub, dovresti prendere il tempo necessario per familiarizzarlo. È uno strumento utile.
Modifica
Come sottolineato da @DanRedux, consente anche di posizionare facilmente i progetti ed esplorare altri percorsi.
In realtà, ci sono poche ragioni per NON usare un repository di codice. Solo il fatto di poter facilmente tornare a qualsiasi versione precedente ha coperto il mio retro così tante volte quando ho introdotto per sbaglio i bug di regressione, nonostante i miei test automatici.
Se hai bisogno di un consiglio - prova Mercurial. È davvero semplice, ma molto potente. Eviterei Git a causa della sua inutile complessità. Certo, questa è solo la mia opinione personale. Quindi scegli quello che ti si addice meglio.
Bene, oggigiorno con la terza generazione di controllo del codice sorgente, non è così difficile iniziare a usarli appositamente git o mercurial , non riesco a pensare a nessuno dei motivi per cui non dovresti usarne nessuno.
Inoltre, se non si desidera impostare un ambiente remoto è possibile utilizzare siti come Github , bitbucket , CodeGoogle per mantenere il tuo sorgente attivo e afferrarlo quando vuoi.
Non sono d'accordo con @Christian git è in realtà una soluzione molto semplice e diretta, ben documentata e molto potente. Personalmente ho usato mercurial poche volte e a breve termine, quindi non posso avere una strong opinione a riguardo.
TL; DR la risposta è Sì, Ja, Si, Oui!
Sono l'unico sviluppatore della mia azienda. Io uso SVN per qualsiasi cosa che attualmente in produzione o potrebbe eventualmente essere in produzione un giorno. Dieci motivi per cui lo uso:
Backup. Se il mio HD fallisce, non voglio perdere tutto il mio codice!
Rende facile il rollback alle versioni precedenti del codice nel caso in cui io faccia qualcosa in modo completo (ti fa sentire più coraggioso quando fai anche refactori di grandi dimensioni)
Semplifica l'installazione di una build continua che esegue i miei test di unità ogni volta che effettuo il check-in
Le build continue creano anche una versione "staging" della mia applicazione per chiunque altro nella società (o per test, o UAT, o demo)
Fornisce una buona storia per il capo (e me) per vedere a cosa sto lavorando
Quando i nuovi programmatori vengono a bordo, posso facilmente indirizzarli verso il codice
Consente di taggare una versione di "rilascio produzione attuale" del codice, nel caso in cui sia necessario distribuire una correzione urgente senza introdurre le nuove funzionalità su cui sto lavorando
Semplifica la gestione di una libreria di codici riutilizzabile condivisa tra più soluzioni (sono nel mondo c #)
Mi tiene aggiornato su tutto ciò che c'è nel mondo SVN (ehi, l'ultima versione di SVN tortoise ti chiede automaticamente di aggiornarti se esegui un commit non aggiornato, bello!). Il bello di lavorare da solo è che è molto più facile testare molte più cose - non devi preoccuparti di rompere il codice / build / test / framework per chiunque altro.
Se non sono ammalato (o festivo, qualunque cosa) il codice non è bloccato sulla mia macchina, il boss può rimuoverlo da SVN.
Serve anche a ricordarmi che sono un ingegnere del software e non solo coding scum:)
Un repository di codice è una cronologia e avere una cronologia non fa mai male. Ho fatto un po 'di cose in una directory di shell bash ~ / bin, e il controllo delle revisioni mi ha salvato. Consideralo anche come un tipo diverso di backup del codice sorgente, a condizione che venga eseguito il backup del repository. Ho ripristinato il software per la riscossione delle imposte della nostra città da CVS, durante la migrazione a una nuova piattaforma Linux, e tutto è stato creato dopo il check-out del repository.
Vorrei usare lo stesso software che usi al lavoro, o qualcosa di più moderno, come git.
Sono d'accordo con Tim, sì, dovresti usare qualche sistema di controllo della versione. Ma vorrei usare qualcosa di semplice dove non è necessario configurare un server. Uso Git per tutti i miei progetti, anche se sono semplici e piccoli (all'inizio ...). Per configurare un repository Git tutto quello che devi fare è git init , quindi è davvero facile. Ovviamente, se non hai ancora utilizzato Git, potrebbe non essere la scelta giusta per te ...
Sicuramente! Solo per il motivo che ti consentirà di riportare il tuo codice alle versioni precedenti, ecc. Il controllo della versione ne vale la pena. C'è solo così tanto "ctrl + z" che si può fare!
Sì per qualcosa di più grande di una piccola sceneggiatura. Uno dei vantaggi è quello di essere in grado di caricare in avanti con un nuovo design e un strong refactoring del tuo codice base senza preoccuparti di cancellare la copia originale o che sarà un grosso problema unire le tue modifiche nella base di codice originale se si determina che le tue modifiche sono pronte per essere avviate.
Per i singoli sviluppatori la domanda si semplifica in "Devo fare i backup del codice sorgente se sono l'unico a lavorare su un progetto". Molto probabilmente lo vorrai.
I vantaggi aggiuntivi sono evidenti rispetto a questo, ma molto probabilmente troverai alcuni di questi molto utili in ogni caso. I vantaggi sono mostrati molto più tardi nel processo.
La seconda caratteristica più utile è la possibilità di costruire i bit che vengono spediti ai clienti in un ambiente pulito. Questo assicura che la build sia riproducibile, il che è molto importante quando è necessario mantenerli in seguito.
I vantaggi di avere il tuo codice in un VCS sono ben documentati. Test di regressione / rollback, possibilità di aggiungere persone in futuro, commentare la cronologia delle modifiche, ecc.
Ma per "progetti" molto piccoli che consistono solo di pochi file o non hanno bisogno di versioni con versioni, potresti essere in grado di farla franca con il controllo della versione assolutamente inferiore al barile usando RCS . RCS è il sistema di controllo di revisione per file su cui CVS è stato originariamente costruito. Se il tuo obiettivo è ottenere i benefici che ho notato sopra, allora RCS lo farà, senza richiedere un repository centralizzato O una curva di apprendimento ripida.
Uso ancora RCS per mantenere una cronologia delle revisioni dei file di configurazione del server, o dei singoli script della shell che non hanno molto senso al di fuori delle loro particolari aree. Una volta che inizi a dover comprimere un numero di file insieme in una versione di "rilascio" di qualcosa, hai superato RCS. Ma ha ancora il suo posto.
My $ 0.02.
Sono su questa barca. Non solo uso il controllo del codice sorgente, ma costruisco tutto il software su una scatola completamente separata.
Questo assicura che tutto il codice sorgente creato sulla mia macchina sia stato effettivamente archiviato al controllo del codice sorgente. Inoltre ho un altro backup di tutto.
Il costo di un'altra macchina è di circa £ 300 nel Regno Unito, quindi IMO non puoi giustificare di non farlo!
Leggi altre domande sui tag version-control solo-development svn java