Non voglio finire con 82 rami di funzionalità in giro , quindi mi chiedo quali siano i potenziali svantaggi della semplice eliminazione del ramo di funzionalità non appena lo unisco al master.
Flusso di lavoro:
git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz
Eventuali problemi qui?
git reflog. Quindi controlla l'hash
Risposte:
L'eliminazione dopo l'unione è il solito modo. Questo è il motivo git branch -d yourbranchnameper cui verifica che il ramo sia completamente unito prima di eliminarlo.
Ci sono alcuni motivi che mi vengono in mente per mantenere un ramo in giro: potresti volerlo tenere nel caso in cui dovessi avere bug che tornano una volta in produzione, o potresti volere un record storico.
In entrambi i casi, hai la possibilità di taggare il capo del ramo prima di eliminarlo. Un tag è come un ramo in quanto è un puntatore a un commit, tranne per alcune piccole differenze: 1) la porcellana di solito non mostra i tag nei comandi esplorativi come git show-branch o tab-auto complete al checkout, 2) controllarne uno ti mette in una HEAD separata (non ref) 3) puoi lasciare un " messaggio di tagging ", che fa sì che il tag venga salvato come oggetto nell'object store come un commit.
In questo modo conservi la cronologia e, se hai bisogno di correggere i bug, ti consiglio di creare un nuovo ramo dal master per la correzione.
Elimino dopo l'unione, ma faccio sempre a git merge --no-ff, per evitare l'avanzamento veloce in modo che la cronologia del ramo sia visibile sul grafico. Mi piace avere la cronologia di dove il ramo delle caratteristiche è partito dal ramo di sviluppo e dove si è unito di nuovo:
Questo è tratto da Un modello di ramificazione Git di successo di Vincent Driessen, un flusso di lavoro molto carino da usare con git che applico per la maggior parte dei miei progetti.
merge --no-ffal master perché come dici tu puoi vedere la cronologia.
Posso pensare a due motivi per cui potresti voler mantenere un ramo di funzionalità per un po ':
In pratica, la maggior parte delle volte l'eliminazione dopo l'unione va benissimo.
Il flusso di lavoro tipico sarà
// Create new branch
$ git checkout -b myfeature
// and then do some changes and commit them
// Switch to master branch
$ git checkout master
// Merge myfeature to master. --no-ff will always keep branch information.
$ git merge --no-ff myfeature
// Delete myfeature branch
$ git branch -d myfeature
// Push the changes
$ git push origin master
penso che sia il flusso di lavoro tipico (eliminazione dopo l'unione)
EDIT Quindi, piuttosto che unire, almeno per i rami di breve durata, penso che l'idea sia di ricondurli al master. quindi si finisce con una cronologia delle modifiche lineare e l'intero ramo diventa parte del tronco principale. in questo caso hai tutte le modifiche lì quindi chiaramente non hai bisogno di una copia.