Sto sviluppando un sito Web in php in localhost e man mano che i moduli vengono completati, lo carico sul cloud in modo che i miei amici possano testarlo alfa.

Mentre continuo a sviluppare, ho molti file e perdo traccia di quale file ho modificato o modificato, ecc. Ho sentito parlare di qualcosa come "controllo versione" per gestire tutti questi, ma non sono sicuro di come funzioni.

Quindi, la mia domanda è: esiste un modo semplice / servizio / applicazione disponibile per tenere traccia di tutte le modifiche / modifiche / nuovi file e gestire i file mentre sviluppo il sito Web. Appena ho finito con un modulo, voglio caricarlo sul cloud (sto usando Amazon Cloud Service). Se succede qualcosa ai nuovi file, potrei voler tornare al vecchio file. E forse, in un clic o due, riesco a vedere i file che ho modificato o modificato dall'ultimo che ho caricato?

La gestione della configurazione del software , di cui fa parte il controllo della versione , è un po 'più complessa rispetto al tenere traccia delle modifiche ai file, anche se si può certamente iniziare con quello. Ma leggi gli articoli di Wikipedia collegati sopra insieme al tutorial di Joel Spolky su Mercurial .

Per iniziare, scegli uno di Mercurial, GIT o Bazaar, in quell'ordine, e installalo insieme agli strumenti per il tuo IDE e 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 è quella di tenere traccia dei 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. Spiega allo strumento gli schemi per i file che non vuoi monitorare (modifica .hgignore per Mercurial).
5. Eseguire un commit per tenere traccia delle versioni originali ( hg ci ).
6. Esegui un commit dopo ogni pietra miliare logica, anche se piccola.
7. Aggiungi nuovi file mentre li crei.
8. Ripeti gli ultimi due.
9. Eseguire il backup della directory di lavoro e del repository con la frequenza ragionevole.

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

È una buona idea taggare ( hg tag ) il repository prima di pubblicare il tuo codice, quindi c'è un modo semplice per tornare esattamente a ciò che hai pubblicato per modifiche o confronti.

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

Se l'esperimento riguarda una nuova versione aggiornata, clona e quindi ramifica (ramo hg ) in modo da poter aggiornare tutte le copie dei repository 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 tenuto un discorso a Google sul perché lo strumento non può essere CVS, SVN o uno dei tanti gratuiti e commerciali in circolazione ; vale davvero la pena guardarlo.

Consiglio vivamente Git. Scopri di più qui: https://lab.github.com/

Se non ti piace Git, ci sono altre soluzioni di controllo della versione. Potresti dare un'occhiata a SVN.

Sei solo tu ?, usa un DVCS

Per quanto contro-intuitivo come sembra, un sistema di controllo della versione distribuita (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 quindi, devi essere connesso ad un server per memorizzare le tue modifiche.

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

IMHO, mercurial è un DVCS più amichevole e altrettanto capace per cominciare.

Ce ne sono altri? Usa un DVCS!

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

Finisci per avere qualcosa del genere, in cui tutti si impegnano ad hoc:

Ognuno si preoccupa solo del proprio lavoro durante il controllo delle versioni (ovvero non correre per impegnarsi) e non preoccuparsi di una connessione a un server solo per impegnarsi.

In bocca al lupo

Per essere brevi, ci sono molte alternative, tra cui Subversion (SVN) e Git sembrano più popolari (quindi più facili da 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, impegnarle ...
4. ... e per fare cose più avanzate (rivedere i registri, ripristinare le modifiche, ignorare i file, creare rami, unirli, creare e usare telecomandi, usare sottomoduli, usare il supporto SVN ecc.).

Spero che questo ti aiuti a iniziare.

Come suggerisce Apalala, ti consiglio di dare un'occhiata a hginit . Dato che sei nuovo nel controllo versione, puoi saltare la prima pagina. Questo dovrebbe darti una buona introduzione, in seguito puoi pubblicare su SO se hai domande specifiche.

Andrò contro l'opinione della maggioranza e consiglierò Subversion. Subversion è facile da usare e fa tutto ciò di cui hanno bisogno gli individui e le piccole squadre. È 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 in realtà non ha bisogno di quelle funzionalità aggiunte.

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 ti capita di fare diverse modifiche discrete e non riesci ad accedere al server del repository - ma onestamente, con che frequenza succede?

Git semplifica la gestione delle ramificazioni e delle fusioni. Ma per un team di una persona non è un grosso problema.

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

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