Struttura di un repository Git

Scusate se questo è un duplicato, ho guardato.

Ci stiamo trasferendo a Git. In Subversion, sono abituato ad avere le cartelle \ trunk, \ branch e \ tags.

Con Git, il passaggio da una filiale all'altra sostituirà il contenuto della directory di lavoro, quindi ho ragione a supporre che il modo in cui lavoravamo non si applica a Git?

La mia ipotesi è che avrei una cartella repository con forse un gitignore e readme.txt, quindi le cartelle per i progetti che compongono il repository, e il gioco è fatto.

Avrai "trunk", ora chiamato "master", avrai "rami" ora chiamati "head" e avrai "tag", ancora chiamati "tag", ma non saranno cartelle , saranno " refs ", etichette per le revisioni che vivono in uno spazio dei nomi separato all'interno del repository.

Subversion e Git hanno modi diversi di fare ramificazione. Il modello di sovversione di base è di avere un albero di directory con una singola linea temporale globale e se si desidera ramificare, si copia un sottostruttura in un'altra directory.

D'altra parte Git ha un albero di directory con revisioni che definiscono ognuna i suoi genitori, ma ogni revisione può avere più genitori (una fusione) e più figli (rami). Quindi, invece di avere directory per le filiali, ottieni revisioni create in modo indipendente. I "riferimenti" sono solo nomi associati all'ultima revisione per un determinato "ramo".

Questa differenza è fondamentale per il controllo della versione distribuita. Git (e altri sistemi distribuiti) non ha alcuna autorità centrale per mantenere la cronologia lineare, quindi le revisioni possono essere create in modo indipendente su più repository senza conoscersi e il sistema deve adattarle. Si scopre che la generalizzazione rende la ramificazione e l'unione molto più facile in generale.

Si noti che in Git le revisioni non sono presenti in alcun ramo. Lo sono e i rami li contengono. Ma una volta che il ramo viene unito, o si rivela essere vicolo morto, puoi semplicemente eliminare il "ref" che lo indica e dimenticartene del tutto (se scarti le vecchie prove, alla fine verranno spazzate via git gc). Questo ti aiuta a evitare di essere sommerso da vecchi esperimenti che nessuno ricorda più di cosa si trattasse.

Pensa a Git come a una vista 3D degli stessi dati che vedi in 2D in SVN - cioè con SVN ramifichi la tua radice e appare come una copia mostrata come una nuova cartella nell'albero. Con Git, quando si ramifica, appare come una copia mostrata come uno "strato" sopra l'albero esistente. Una volta che ti rendi conto che è abbastanza facile concettualizzare la differenza.

Con SVN puoi ancora lavorare allo stesso modo di Git - switch tra i rami sostituirà la vista singola della base di codice con la vista ramificata, questo vale se usi svn switch o git checkout.

Ovviamente puoi ottenere una copia di un ramo in SVN controllando il ramo nella sua posizione della cartella, che è lo stesso della clonazione di un repository git in una posizione diversa sul tuo disco.

Lo stesso vale per i tag: puoi etichettare una revisione git o creare un ramo per una versione. I tag SVN sono gli stessi dei rami, la sua unica convenzione è che sono chiamati "tag". È possibile etichettare (bene, registrare il numero di revisione) di un repository SVN per ottenere anche un'istantanea di una versione.

Le differenze tra git e svn hanno più a che fare con il modo in cui avvengono check-in e check-out, non con i fondamenti del controllo del codice sorgente. La vista del codice può essere diversa (non vedrai mai un'unica vista dell'albero del codice che includa i rami in git e puoi ramificare un repository parziale in SVN, ma alla fine si tratta di differenze minori)