Attualmente sto imparando ad usare Git leggendo Pro Git . In questo momento sto imparando su branching e tag. La mia domanda è quando devo usare un ramo e quando dovrei usare un tag?

Ad esempio, supponiamo che crei un ramo per la versione 1.1 di un progetto. Al termine e rilascio di questa versione, devo lasciare il ramo per contrassegnare la versione di rilascio? O dovrei aggiungere un tag? Se aggiungo un tag, devo eliminare il ramo della versione (supponendo che sia unito nel master o in qualche altro ramo)?

In breve: le migliori pratiche sono diramazioni, si fondono spesso e si mantengono sempre sincronizzate .

Esistono convenzioni piuttosto chiare sul mantenimento del codice in rami separati da quello principale:

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

La regola empirica è dopo la ramificazione, è necessario essere sincronizzati con il ramo principale. Perché alla fine è necessario ricollegarlo al master. Al fine di evitare un enorme disordine complicato di conflitti durante la fusione, è necessario impegnarsi spesso, unire spesso.

Buone pratiche da seguire

Un modello di ramificazione Git di successo di Vincent Driessen ha buoni suggerimenti. Se questo modello di diramazione ti piace prendere in considerazione l' estensione del flusso su git . Altri hanno commentato il flusso .

Pratiche di etichettatura

Come già sai, Git ti dà identificativi di commit come 1.0-2-g1ab3183 ma quelli non sono tag! La codifica viene eseguita con il tag git, e i tag creati utilizzando il tag git sono la base per gli identificativi di commit che git descrive crea. In altre parole, in Git non tag i rami. Stai taggando i commit. È corretto affermare che il tag è solo un puntatore annotato a un commit.

Vediamo l'esempio pratico che lo ha dimostrato,

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

Commettiamo 'S' sia commit indicato dal tag 'v1.0'. Questo commit è sia sul ramo 'master' che sul ramo 'test'. Se esegui " git descritto " sopra il commit "A" (in cima al ramo "master") otterrai qualcosa del genere v1.0-2-g9c116e9. Se esegui "git descritto" sopra il commit "A" (noto anche come ramo "test") otterrai qualcosa del genere v1.0-2-g3f55e41, come nel caso della configurazione predefinita di git-description. Si noti che questo risultato è leggermente diverso. v1.0-2-g9c116e9significa che stiamo eseguendo il commit con ID SHA-1 ordinato di 9c116e9, 2 commit dopo tag v1.0. Non ci sono tag v1.0-2!

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

Riferimenti

Ho trovato molti, molti, utili blog e post da cui imparare. Tuttavia, quelli illustrati professionalmente sono rari. Quindi, vorrei raccomandare un post - Un modello di ramificazione Git di successo di @nvie. Ho preso in prestito la sua illustrazione :)

Un ramo viene utilizzato se si hanno 2 versioni diverse di repository contemporaneamente. Un tag è un modo per contrassegnare un punto nel tempo nel repository.

È necessario aggiungere un tag per contrassegnare una versione rilasciata. Se è quindi necessario apportare correzioni di bug a tale versione, è necessario creare un ramo nel tag.

Desideri eliminare solo i rami che sono stati riuniti nuovamente in HEAD [o in qualche altro ramo].