perché dovrei eliminare i rami delle funzioni quando sono uniti al master

Question

La maggior parte dei flussi di lavoro di git che ho visto suggeriscono di eliminare un branch dopo che è stato fuso in master. Ad esempio, questo gitflow suggerisce quanto segue:

# Incorporating a finished feature on develop 
$ git checkout develop 
Switched to branch 'develop' 
$ git merge --no-ff myfeature 
Updating ea1b82a..05e9557 
(Summary of changes) 
$ git branch -d myfeature 
Deleted branch myfeature (was 05e9557). 
$ git push origin develop 

Perché dovrei cancellare il ramo? Sono anche curioso di sapere cosa fare quando in seguito verrà scoperto un bug introdotto dalla funzione: dovrei creare di nuovo il ramo con lo stesso nome, correggere il bug, unirmi al master e cancellare nuovamente il ramo?

Answer 1

Qualcosa di importante da realizzare è che i rami Git non sono altro che un'etichetta che punta a un commit. Branching in Git è letteralmente ramificato. Ecco quello che un repository appare come se feature diramava master quando master stato un commit B.

A - B - C - F - H [master] 
    \ 
     D - E - G - I[feature] 

Vedi? Ramo attuale Quando si git merge feature in master, si ottiene questo.

A - B - C - F - H - J [master] 
    \   /
     D - E - G - I [feature] 

E una volta che la storia git branch -d feature ramo rimane!

A - B - C - F - H - J [master] 
    \   /
     D - E - G - I 

J ha i genitori H e I. J non può esistere senza di loro, è cotto in come funziona Git. Non posso esistere senza G. G non può esistere senza E. E così via. Il ramo deve rimanere

J è un commit merge che in genere conterrà il nome del ramo da unire. È come qualsiasi altro commit, quindi puoi anche aggiungere più informazioni ad esso, come un link al tuo tracker di problemi.

git merge --no-ff viene utilizzato per impedire a Git di eseguire un "avanzamento rapido" e di perdere la cronologia del ramo. Ciò accade se non è stato eseguito alcun lavoro su master da quando è stato creato il ramo. Un fast-forward sembra così.

A - B[master]- D - E - G - I [feature] 

git checkout master 
git merge feature 

A - B - D - E - G - I [feature] [master] 

Da master è un antenati del feature, non è richiesta alcuna unione. Git può semplicemente spostare l'etichetta master. La cronologia del tuo ramo è andata persa, sembra che D, E, G e I siano stati tutti fatti come singoli commit sul master. git merge --no-ff dice a Git di non farlo mai, per eseguire sempre l'unione.

In futuro, quando viene rilevato che un errore è stato introdotto in G, chiunque sfoglia il repository può vedere che è stato eseguito come parte del ramo, guardare avanti per trovare il commit di unione e ottenere informazioni sul ramo da lì.

Anche così, perché eliminare il ramo?Due ragioni. In primo luogo, ingombrerà la tua lista di rami con rami secchi.

In secondo luogo, e più importante, impedisce di riutilizzare il ramo. La ramificazione e la fusione sono complicate. Le filiali di funzioni monouso e di breve durata semplificano il processo assicurandovi di reinserire il ramo sempre nel master una volta. Questo elimina molti problemi tecnici e di gestione. Quando unisci un ramo, è fatto. Se devi risolvere un problema introdotto in quel ramo, consideralo come un bug in master e crea un nuovo ramo per risolverlo.

Sfortunatamente, git log giace all'utente e presenta una rappresentazione lineare della cronologia che non è lineare. Per risolvere questo problema, utilizzare git log --graph --decorate. Questo disegnerà linee come nei miei esempi sopra e ti mostrerà ogni ramo e tag su ogni commit. Avrai una visione molto più accurata del repository.

Se sei su un Mac, GitX visualizzerà il repository per te. gitk è la versione generica.

Answer 2

Poiché la cronologia di succursale myfeature rappresenta tutti i commit intermedi eseguiti per implementare myfeature.

Questa strategia mantiene un solo commit in master e dimentica i passaggi intermedi, il che ha senso per i rami longeva, come ho spiegato in "Why does git fast-forward merges by default?".

Il messaggio di commit del commit eseguito (unito) in master dovrebbe rendere chiaro che è stato fatto per l'implementazione di 'myfeature'.

Se è necessario ripararlo, è possibile riutilizzare il nome del ramo (poiché è stato eliminato prima).