In breve: la best practice è si dirama, si unisce spesso e si mantiene sempre sincronizzato .

Esistono convenzioni abbastanza chiare su come mantenere il codice in rami separati dal ramo principale:

1. Stai per realizzare un'implementazione di modifiche importanti o dirompenti
2. Stai per apportare alcune modifiche che potrebbero non essere utilizzate
3. Vuoi sperimentare su qualcosa che non sei sicuro funzionerà
4. Quando ti viene detto di espandersi, gli altri potrebbero avere qualcosa che devono fare nel master

La regola empirica è dopo il diramazione, è necessario rimanere sincronizzati con il ramo principale. Perché alla fine è necessario unirlo nuovamente al master. Per evitare un enorme e complicato caos di conflitti durante la fusione, dovresti eseguire spesso il commit, unire spesso.

Buone pratiche da seguire

Un riuscito modello di branching Git di Vincent Driessen ha buoni suggerimenti Se questo modello di ramificazione ti fa appello, considera l' estensione del flusso per git . Altri hanno commentato sul flusso .

Pratiche di tagging

Come già sai, Git ti fornisce identificatori di commit come 1.0-2-g1ab3183 ma quelli non sono tag! Il tagging è fatto con il tag git, e i tag che vengono creati usando il tag git sono la base per gli identificatori di commit che git descrive crea. In altre parole, in Git non tagghi i rami. Stai taggando i commit. È corretto dire che il tag è solo un puntatore annotato su un commit.

Vediamo un esempio pratico che lo ha dimostrato,

                        /-- [v1.0]
                       v
---.---.---.---S---.---A     <-- master
                         \ 
                           \-.---B     <-- test

Impegniamoci con "S" come commit indicato dal tag "v1.0". Questo commit è sia sul ramo 'master' che sul ramo 'test'. Se esegui " git describe " in cima al commit 'A' (in cima al ramo 'master') otterresti qualcosa come v1.0-2-g9c116e9 . Se si esegue "git describe" sopra a commit "A" (ovvero il ramo "test") si otterrebbe qualcosa come v1.0-2-g3f55e41 , come nel caso della configurazione predefinita git-describe. Si noti che questo risultato è leggermente diverso. v1.0-2-g9c116e9 significa che siamo in commit con ID SHA-1 sorted di 9c116e9 , 2 commit dopo il tag v1.0 . Non c'è tag v1.0-2 !

Se vuoi che il tuo tag appaia solo sul ramo "master", puoi creare un nuovo commit (ad esempio, aggiornare solo le informazioni sulla versione di default / fallback in GIT-VERSION-FILE) dopo il punto di diramazione del ramo "test". Se contrassegni i commit sul ramo "test" con ad es. 'v1.0.3' sarebbe visibile solo da 'test'.

Riferimenti

Ho trovato molti, molti blog e post utili da cui imparare. Tuttavia, quelli che sono illustrati professionalmente sono rari. Pertanto, mi piacerebbe raccomandare un post - un riuscito modello di branching Git di @nvie. Ho preso in prestito la sua illustrazione:)

Un ramo è usato se hai 2 diverse versioni del repository allo stesso tempo. Un tag è un modo per contrassegnare un punto nel tempo nel tuo repository.

Dovresti aggiungere un tag per contrassegnare una versione rilasciata. Se è necessario apportare correzioni di bug a tale versione, si creerà un ramo sul tag.

Devi solo eliminare i rami che sono stati uniti in HEAD [o qualche altro ramo].