Scusa se questo è un duplicato, ho guardato.
Ci stiamo trasferendo a Git. In Subversion, sono abituato ad avere \ trunk, \ branches e \ tags folders.
Con Git, il passaggio da un ramo all'altro sostituirà il contenuto della directory di lavoro, quindi ho ragione nel ritenere che il modo in cui lavoravamo non si applicasse a Git?
La mia ipotesi è che avrei una cartella Repo con forse un gitignore e readme.txt, poi le cartelle per i progetti che compongono il repository, e il gioco è fatto.
Avrai "trunk", ora chiamato "master", avrai "rami" ora chiamati "teste" e avrai "tag", ancora chiamati "tag", ma loro non saranno cartelle , saranno "ref", etichette alle revisioni che vivono in uno spazio dei nomi separato all'interno del repository.
Subversion e Git hanno diversi modi di fare branching. Il modello di subversion di base è quello di avere un albero di directory con un'unica timeline globale e se si desidera diramazione, si copia una sottostruttura in un'altra directory.
D'altra parte Git ha un albero di directory con revisioni che ciascuno definisce i suoi genitori, ma ogni revisione può avere più genitori (un'unione) e più figli (rami). Quindi, invece di avere le directory per le filiali, ottieni revisioni create in modo indipendente. I "ref" sono solo nomi associati all'ultima revisione per "ramo" dato.
Questa differenza è fondamentale per il controllo della versione distribuita. Git (e altri sistemi distribuiti) non ha alcuna autorità centrale per mantenere lineare la cronologia, quindi è possibile creare revisioni in modo indipendente su più repository senza conoscersi l'un l'altro e il sistema deve adattarli. Si scopre che la generalizzazione rende molto più semplice la ramificazione e la fusione in generale.
Nota che in Git le revisioni non sono su alcun ramo. Sono solo e rami li contengono. Ma una volta che il ramo è fuso, o si rivela un vicolo cieco, puoi semplicemente eliminare il "ref" puntandolo ad esso e dimenticarlo del tutto (se scarti vecchi processi, saranno raccolti con il garbage alla fine con git gc ). Questo ti aiuta a evitare di essere sommersi da vecchi esperimenti 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 diramai la tua radice e appare come una copia mostrata come una nuova cartella nell'albero. Con Git, quando si dirama, appare come una copia mostrata come un "livello" ontop dell'albero esistente. Una volta che ti rendi conto che è piuttosto facile concettualizzare la differenza.
Con SVN puoi ancora lavorare allo stesso modo di Git: passare da una filiale all'altra sostituirà la vista singola della base di codice con la vista ramificata, questo vale sia che tu stia utilizzando svn switch o git checkout.
Ovviamente è possibile ottenere una copia di un ramo in SVN controllando il ramo nel suo percorso di cartella, che è lo stesso di clonazione di un repository git in una posizione diversa sul disco.
Lo stesso vale per i tag - puoi etichettare una revisione di git, oppure puoi creare un ramo per una versione. I tag SVN sono gli stessi dei branch, la loro unica convenzione sono chiamati 'tags'. È possibile etichettare (beh, registrare il numero di revisione) di un repository SVN per ottenere anche un'istantanea di un rilascio.
Le differenze tra git e svn hanno più a che fare con il checkin e il checkout, non con i fondamenti del controllo del codice sorgente. La vista del codice può essere diversa (non vedrai mai una singola vista dell'albero del codice che include rami in git, e puoi diramare un repository parziale in SVN, ma queste sono in definitiva differenze minori)
Leggi altre domande sui tag git version-control