Gestione della configurazione del software , di cui Version Control è parte, è un po 'più complesso di tenere traccia delle modifiche ai file, anche se puoi certamente iniziare con quello. Leggi gli articoli di Wikipedia linkati sopra insieme al tutorial di Joel Spolky su Mercurial .

Per iniziare, scegli uno di Mercurial, GIT o Bazaar, in questo ordine, e installalo insieme agli strumenti per l'IDE e il sistema operativo (preferisco Mercurial con HGE per Eclipse).

1. Inizializza un repository dalla tua directory di lavoro ( hg init con Mercurial) ..
2. Decidi quali file e directory vuoi monitorare e quali no. La regola generale non è tracciare i file generati da compilatori e altri strumenti.
3. Utilizzare il comando per aggiungere i file e le directory al repository ( hg add per Mercurial).
4. Indica allo strumento i pattern per i file che non vuoi tracciare (modifica .hgignore per Mercurial).
5. Esegui un commit per tracciare le versioni originali ( hg ci ).
6. Esegui un commit dopo ogni traguardo logico, anche se di dimensioni ridotte.
7. Aggiungi nuovi file mentre li crei.
8. Ripeti gli ultimi due.
9. Effettua il backup della directory di lavoro e del repository con la frequenza più ragionevole possibile.

Con i tuoi file nel repository, puoi conoscere le differenze tra due versioni di un file o di una directory, o il progetto completo ( hg diff ), vedere la cronologia delle modifiche ( hg hist ) e ripristina le modifiche ( hg up -r ).

È una buona idea taggare ( tag hg ) il repository prima di pubblicare il tuo codice, in modo che sia facile tornare a quello che hai pubblicato per modifiche o confronti.

Se vuoi sperimentare una diversa linea di sviluppo, fallo in un semplice ramo clonando il repository principale ( hg clone ) e non spingendo indietro fino a quando l'esperimento non è conclusivo. È facile avere una directory di lavoro diversa per l'esperimento.

Se l'esperimento è per una nuova versione aggiornata, clona e poi dirama ( hg branch ) in modo da poter mantenere tutte le copie dei repository aggiornate senza che un esperimento interferisca con l'altro.

Linus Torvalds (che si occupa di decine di migliaia di file e milioni di righe di codice nei suoi progetti) ha dato un parla a Google sul perché lo strumento non può essere CVS, SVN o uno qualsiasi dei tanti gratuiti e commerciali in circolazione; vale davvero la pena guardare.

Consiglio vivamente Git. Scopri qui: link

Se Git non ti piace, ci sono altre soluzioni per il controllo della versione. Potresti controllare SVN.

Sei solo tu ?, usa un DVCS

Per quanto controintuitivo possa sembrare, un sistema di controllo delle versioni distribuite (mercurial, git, bazaar) è meglio iniziare rispetto a un sistema centralizzato (svn, cvs). Perché ?, lo installi sul tuo computer ed esegui il tuo repository localmente, e il gioco è fatto. Su un sistema centralizzato come svn devi configurare il tuo client e un server ... e poi, devi essere connesso a un server per memorizzare le tue modifiche.

Con un DVCS sei tu, il repository locale, e se vuoi, puoi usare un servizio come bitbucket.org o github.com.

IMHO, mercurial è un DVCS più amichevole e altrettanto capace da cui partire.

Ce ne sono altri ?, usa un DVCS!

Ci sono numerosi vantaggi quando si utilizza un DVCS per lavorare con una squadra, il più importante in contrasto con un sistema centralizzato è che non ci sono gare di commit e questo perché, tecnicamente, il repository individuale è un ramo e quando condividi i tuoi cambiamenti quei rami sono uniti per te e non te ne accorgi nemmeno, il che significa che invece di avere una cronologia delle versioni come questa, dove hai persone che incanalano il loro lavoro su una linea retta: / p>

Finisciperaverequalcosadisimile,dovetuttisilimitanoacommettereadhoc:

Ognuno si preoccupa solo del proprio lavoro durante il controllo delle versioni (cioè non è in corsa per il commit) e non si preoccupa di una connessione a un server solo per il commit.

Buona fortuna

Per essere brevi, ci sono molte alternative, tra cui Subversion (SVN) e Git sembrano più popolari (quindi è più facile trovare soluzioni sul web).

Entrambi differiscono. SVN è più semplice, ma Git non richiede di avere un server con cui iniziare - puoi controllare la versione localmente.

Supponendo che tu abbia Linux e desideri iniziare a usare Git:

1. Installa Git
2. Vai alla directory ed esegui il comando 'git init'
3. Scopri come aggiungere file, rivedere le modifiche, confermarle ...
4. ... e per fare cose più avanzate (rivedere i registri, annullare le modifiche, ignorare i file, creare rami, unirli, creare e utilizzare i telecomandi, usare i sottomoduli, usare il supporto SVN ecc.).

Spero che questo ti aiuti ad iniziare.

Come suggerito da Apalala, ti consiglio di effettuare il check out hginit . Dato che sei nuovo nel controllo della versione puoi saltare la prima pagina. Questo dovrebbe darti una buona introduzione, dopodiché puoi pubblicare su SO se hai domande specifiche.

Vado contro l'opinione della maggioranza e raccomando Subversion. Subversion è facile da usare e fa tutto ciò che gli individui e i piccoli team hanno bisogno. È un prodotto maturo, quindi ogni IDE là fuori ha un buon supporto per questo. Sì, non ha tutte le caratteristiche di Git. (Non ho mai usato Mercurial, quindi non ne parlerò.) Ma la maggior parte degli sviluppatori non ha realmente bisogno di quelle funzionalità aggiuntive.

Repository multipli? Sono sicuro che ci sono alcuni usi legittimi per quelli, ma non li ho mai incontrati.

Essere in grado di effettuare commit locali, senza accesso alla rete? È bello avere, se stai facendo molte modifiche discrete, e non puoi accedere al server del repository, ma onestamente, quanto spesso accade?

Git semplifica la gestione di ramificazioni e fusioni. Ma per una squadra di una sola persona, non è un grosso problema.

Per qualcosa sulla scala del kernel di Linux - sì, usa Git. Per il resto di noi, Subversion è abbastanza buono.

Penso che un Sistema di controllo della versione distribuita andrà bene. Le scelte comunemente suggerite sono Git e Mercurial (Hg). Gli strumenti grafici possono essere utili, per Mercurial I consigliamo TortoiseHg .