Version Control with Git

[giannino1995]

Ciao a tutti,

Ho letto la prima pagina di un capitolo relativo a Git sul mio libro di php e ne ho solo capito l'utilità. Essendo un programmatore alle prime armi, lontano da un impiego lavorativo a breve termine con molte altre lacune ancora da sanare come Zend, Javascript, ecc... e poca esperienza ritengo che sia doveroso saltarlo e ripassarci sopra in un secondo momento. Le mie domande sono solo 2:

1) Meglio Git, Subversion oppure ancora Mercurial?

2) Mi spiegate in breve il principio di funzionamento? (no link o pagine interminabili solo parole vostre)

A presto e grazie come sempre

[.Kurt]

Meglio Git, Subversion oppure ancora Mercurial?

E' come chiedersi: "è meglio la macchina, il treno o l'aereo?". Nessuno è migliore dell'altro, sono sistemi diversi. Se vuoi sapere in cosa sono diversi non ti resta che documentarti su tutti e tre.

Mi spiegate in breve il principio di funzionamento? (no link o pagine interminabili solo parole vostre)

Arriva alla fine del capitolo e se non hai capito una parte qui possiamo chiarirtela. (Nota che "a cosa serve?" e "qual'è il principio di funzionamento/come funziona" sono due domande ben diverse.)

[MItaly]

Inizia ad informarti su cosa sia un sistema di source control (che secondo me è imprescindibile nel momento in cui sviluppi un progetto appena al di là dell'Hello World), poi possiamo ragionare sulle specificità di git, subversion e Mercurial...

[giannino1995]

Io vorrei solo capire il principio di funzionamento, non ho chiesto nulla relativamente all'utilizzo. In pratica quando un utente corregge un file l'altro non vi può accedere e sa che il collega ci sta lavorando? Proprio non potete spendere due parole sulla mia domanda?

Per la 1 ringrazio MItaly per la risposta.

[MItaly]

Quello era il modo in cui funzionavano alcuni vecchi VCS (mi pare ad esempio Visual SourceSafe 6 e precedenti), ma è un modo di lavorare estremamente scomodo, tutti i VCS moderni consentono modifiche più o meno scoordinate nella sandbox/working copy locale, che vengono poi unite (automaticamente se possibile) al momento in cui si caricano le modifiche altrui (svn update o git pull) o al momento dell'invio delle modifiche su un eventuale server centrale (git push). In ogni caso per modifiche "grosse" in genere si preferisce creare un branch per poter lavorare in pace (eventualmente incorporando via via i cambiamenti dal trunk) per poi effettuare il merge del branch nel trunk una volta terminati i lavori.