In breve: La best practice è ramificarsi, unire spesso e rimanere sempre sincronizzati .

Ci sono convenzioni abbastanza chiare per mantenere il codice in rami separati dal ramo principale:

1. Stai per implementare un cambiamento importante o dirompente
2. Stai per 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 ramificarti, altri potrebbero avere qualcosa da fare nel master

La regola generale è che dopo la ramificazione, dovresti rimanere sincronizzato con il master ramo. Perché alla fine è necessario unirlo di nuovo al master. Al fine di evitare un enorme e complicato pasticcio di conflitti durante la fusione, dovresti eseguire il commit spesso, unire spesso.

Buone pratiche da seguire

Un modello di ramificazione Git di successo di Vincent Driessen offre buoni suggerimenti. Se questo modello di ramificazione ti piace, considera l estensione di flusso a 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 viene eseguito con git tag ei tag che vengono creati utilizzando git tag sono la base per gli identificatori di commit che git descrive crea. In altre parole, in Git non si taggano i rami. Si taggano i commit. È corretto dire che il tag è solo un puntatore annotato a un commit.

Vediamo un esempio pratico che lo ha dimostrato,

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

Lascia che “s commit” S “sia puntato dal tag” v1.0 “. Questo commit è sia sul ramo “master” che sul ramo “test”. Se esegui " git description " sopra il commit ” A “(allinizio del ramo” master “) si otterrebbe qualcosa come v1.0-2-g9c116e9. Se esegui " git description " sopra il commit “B” (noto anche come ramo “test”) otterrai qualcosa come v1.0-2-g3f55e41, questo è il caso della configurazione git-description predefinita. Notare che questo risultato è leggermente diverso. v1.0-2-g9c116e9 significa che siamo in fase di commit con ID SHA-1 ordinato di 9c116e9, 2 commit dopo il tag v1.0. Non cè nessun tag v1.0-2!

Se vuoi che il tuo tag appaia solo sul ramo “master”, puoi creare un nuovo commit (ad es. Solo aggiornamento predefinito / fallback informazioni sulla versione in GIT-VERSION-FILE) dopo il punto di diramazione del ramo “test”. Se tagghi 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, vorrei consigliare un post – Un modello di ramificazione Git di successo di @nvie. Ho preso in prestito la sua illustrazione:)

Commenti

• 1.0-2-g1ab3183 è un identificatore costruito da git descrivere dalle informazioni disponibili da git, ma chiamarlo un identificatore git è un po troppo. Git si identifica tramite hash SHA; tag e rami sono costrutti umani di cui git tiene utilmente traccia. Pertanto, crea un tag quando pensi che un giorno un essere umano desidererà trovare un comodo segnalibro per un commit.
• una meravigliosa illustrazione della multidimensionalità nelluniverso git. bellissimo. grazie
• notando che molti progetti non ne hanno bisogno delle corsie mostrate in questo diagramma. Alcuni progetti richiedono solo ciò che ' chiama sviluppo e funzionalità qui. Questo è spesso vero per le app Web che possono essere distribuite a piacimento.
• Anche lautore di git flow non lo consiglia più per molti tipi di progetti, come lo sviluppo web. Molte persone credono che sia molto più complesso di quanto necessiti la stragrande maggioranza dei progetti, il che rende problematico lesecuzione e facile sbagliare.Allaltra estremità dello spettro, alcuni professionisti avanzati sostengono che i team utilizzano lo ' sviluppo basato su trunk ', che non utilizza quasi mai rami, e realizzare progetti di successo come quello. Per qualcosa di intermedio, considera " anti-gitflow '

Un ramo viene utilizzato 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 poi hai bisogno di correggere i bug di quella versione, creeresti un ramo nel tag.

Vuoi solo eliminare i rami che sono stati uniti nuovamente in HEAD [o qualche altro ramo]. p>

Commenti

• oh … e presumo che tu intenda che il ramo è unito a un altro ramo, come master. HEAD si sposta ogni volta che eseguo un checkout, giusto?
• HEAD di solito punta a un ramo (a meno che ' non sia in modalità HEAD separata), quindi HEAD si sposta con il ramo a cui punta