Quando eliminare i rami in Git?

Supponiamo di avere un'applicazione stabile.

Domani, qualcuno segnala un grosso bug che decidiamo di aggiornare immediatamente. Quindi creiamo un ramo per quell'aggiornamento rapido da "master", lo chiamiamo "2011_Hotfix" e lo spingiamo su in modo che tutti gli sviluppatori possano collaborare per risolverlo.

Risolviamo il bug e uniamo "2011_Hotfix" in "master" e nel ramo di sviluppo corrente. E spingere "maestro".

Cosa facciamo ora con "2011_Hotfix"? Dovrebbe semplicemente rimanere lì fuori come un ramo per sempre fino alla fine dei tempi o dovremmo ora eliminarlo, dal momento che ha servito al suo scopo? Sembra impuro lasciare solo rami in giro dappertutto, poiché l'elenco dei rami probabilmente diventerà molto lungo, la maggior parte dei quali non è nemmeno più necessaria.

Nel caso in cui debba essere eliminato, cosa accadrà alla sua storia? Sarà mantenuto, anche se il ramo effettivo non è più disponibile? Inoltre, come rimuoverei un ramo remoto?

Puoi rimuovere in sicurezza un ramo con git branch -d yourbranch. Se contiene modifiche non unite (ad esempio, perderai i commit eliminando il ramo), git ti dirà e non lo eliminerà.

Quindi, eliminare una filiale unita è economico e non ti farà perdere alcuna cronologia.

Per eliminare un ramo remoto, utilizzare git push origin :mybranch, supponendo che il nome remoto sia origine e che il ramo remoto che si desidera eliminare sia denominato mybranch.

Quello che devi fare è taggare tutto ciò che rilasci. Mantieni i rami intorno per quando stai sviluppando attivamente.

Elimina i vecchi rami con

git branch -d branch_name

Eliminali dal server con

git push origin --delete branch_name

o la vecchia sintassi

git push origin :branch_name

che si legge come "non inviare nulla in branch_name all'origine".

Detto questo, fino a quando il DAG (grafico aciclico diretto) può indicarlo, gli impegni saranno presenti nella storia.

Google "git-flow" e che potrebbe fornire ulteriori informazioni sulla gestione delle versioni, la diramazione e la codifica.

Poiché la domanda ha il tag "github", aggiungerei anche questo: in particolare in Github , se richiedi pull un ramo e viene unito (tramite l'interfaccia utente o unendo il ramo della richiesta pull), non lo farai perdere i dati della richiesta pull (inclusi i commenti), anche se si rimuove il ramo .

Una conseguenza di ciò: se si incorporano richieste pull come parte del flusso di lavoro (che si fonde dolcemente con le revisioni del codice), è possibile eliminare in sicurezza i rami non appena vengono uniti. Questo è così comune che recentemente Github ha aggiunto una funzione (dolce) che fa apparire un pulsante "Elimina ramo" subito dopo aver unito una richiesta pull.

Ma vale la pena notare che ogni gruppo dovrebbe adottare il flusso di lavoro che meglio si adatta (e può o meno portare all'eliminazione di tali rami). Il mio attuale team di lavoro, ad esempio, elimina tutti i rami che non sono correlati al master o alla distribuzione (ad esempio produzione, gestione temporanea, ecc.) Non appena le loro richieste pull vengono unite e abbiamo ancora un monitoraggio completo di come si sono formati i relativi commit ogni miglioramento incrementale di ciascun prodotto.

Ovviamente nessuna gestione della cronologia (richieste pull o altro) sostituisce la corretta codifica delle versioni (che preferisci automatizzare con lo stesso strumento / script che distribuisce / impacchetta una versione), così puoi sempre passare rapidamente a qualunque cosa accada i tuoi utenti in un dato momento. La codifica è anche la chiave per risolvere il problema originale: se si stabilisce che qualsiasi ramo unito ai rami "lavoro" può e deve essere eliminato e che chiunque sia unito a un tag versione, "produzione", ecc. Non dovrebbe , avrai sempre gli hotfix attivi fino a quando non saranno integrati in una versione futura.

Vorrei aggiungere che lo svantaggio dell'eliminazione dei rami è che si interromperanno i collegamenti ipertestuali a quei rami su GitHub (questa domanda è contrassegnata con github). Verrà visualizzato un 404 Not Founderrore per tali collegamenti. Questo è il motivo per cui cambio i miei collegamenti per puntare a un commit o tag dopo aver eliminato un ramo su GitHub.

Poiché alcuni collegamenti non possono essere modificati, ad esempio via e-mail, evito ora il collegamento ipertestuale ai rami GitHub e il collegamento a un commit o tag dal primo giorno.

Preferisco eliminare i rami dopo che sono stati uniti. Questo evita il disordine visivo di un lungo elenco di rami nel tuo repository. Questi rami vengono inoltre propagati a tutte le fork del repository.

Per prima cosa elimino il mio ramo locale. Ciò impedisce che venga spinto accidentalmente in seguito.

git branch -d branchName

Quindi cancello il ramo di tracciamento remoto

git branch -dr remoteName\branchName

Quindi cancello il ramo su GitHub. Uso l'interfaccia web, ma il comando equivalente è sotto.

git push remoteName :branchName

Anche se il ramo non viene mai unito, in genere vorrei comunque mantenere gli impegni per i posteri. Comunque mi piace ancora cancellare il ramo. Per diffondere i commit e impedire che vengano mangiati dal Garbage Collector, creo un tag annotato che punta allo stesso commit del ramo eliminato.

git tag -a tagName commitOrBranchName

Quindi spingo il tag su github

git push remoteName tagName

Sembra che tu voglia eliminare il 2011_Hotfixramo senza perdere la sua cronologia. Discuterò prima della cancellazione e poi della storia.

I soliti gitmetodi di eliminazione dei rami sono già stati descritti sopra e funzionano come previsto. gitnon ha un comando di una o due parole che significa "Ehi git, cancella sia il ramo locale che remoto." Ma questo comportamento può essere imitato tramite shell script. Ad esempio, prendi lo script shell di Zach Holman 'git-nuke' . È molto semplice:

#!/bin/sh
git branch -D $1
git push origin :$1

Inseriscilo in un file eseguibile (ad es. git-nuke) In una delle tue $PATHdirectory. Se non sei sul 2011_Hotfixramo, semplicemente eseguendo git-nuke 2011_Hotfixeliminerai sia i rami locali che remoti. Questo è molto più veloce e più semplice - anche se forse più pericoloso - rispetto ai gitcomandi standard .

La tua preoccupazione per preservare la storia è buona. In questo caso, non devi preoccuparti. Una volta che si uniscono 2011_Hotfixsu master, tutti i commit da 2011_Hotfixverrà aggiunto al master's commettere storia. In breve, non perderai la storia da una semplice unione.

Ho un'altra parola da aggiungere che forse va oltre lo scopo della tua domanda, ma è comunque pertinente. Immaginiamo che ci siano 20 piccoli impegni di "work-in-progress" 2011_Hotfix; tuttavia, si desidera 2011_Hotfixaggiungere un solo commit completo alla mastercronologia. Come unisci tutti i 20 piccoli commit in un unico grande commit? Fortunatamente, gitconsente di consolidare più commit in un solo commit utilizzando git-rebase. Non spiegherò qui come funziona; tuttavia, se sei interessato, la documentazione pergit-rebase è eccellente. Nota che git rebaseriscrive la storia, quindi dovrebbe essere usata con giudizio, specialmente se sei nuovo. Infine, il tuo 2011_Hotfixscenario riguarda una squadra di sviluppo, non uno da solista. Se i membri del team di progetto utilizzanogit rebase, è saggio che il team abbia esplicite linee guida sull'uso git rebasein modo che alcuni sviluppatori di cowboy del team non danneggino involontariamente la gitstoria di un progetto .

Se è stato unito con successo e forse anche taggato, direi che non serve più. Quindi puoi farlo tranquillamente git branch -d branchname.

Se si desidera potare i rami locali che sono stati rimossi dall'origine, è anche possibile potare, durante l'utilizzo git fetch

git fetch --prune

Puoi eliminare i rami in tutte le principali UI Web come github, BitBucket. Dopo aver eliminato il ramo online, è possibile eliminare il ramo locale utilizzando

git remote prune origin