Quali sono alcuni esempi di pratiche comunemente usate per nominare i rami git? [chiuso]


1121

Sto usando un repository git locale che interagisce con il repository CVS del mio gruppo per diversi mesi, ormai. Ho creato un numero quasi nevrotico di rami, la maggior parte dei quali si è fortunatamente ricollegata al mio tronco. Ma la denominazione sta iniziando a diventare un problema. Se ho un compito facilmente chiamato con una semplice etichetta, ma lo compio in tre fasi che includono ciascuna il proprio ramo e uniscono la situazione, allora posso ripetere ogni volta il nome del ramo, ma ciò rende la storia un po 'confusa. Se divento più specifico nei nomi, con una descrizione separata per ogni fase, i nomi dei rami iniziano a diventare lunghi e ingombranti.

Ho imparato a guardare attraverso i vecchi thread qui che potrei iniziare a nominare i rami con un / nel nome, cioè argomento / attività o qualcosa del genere. Potrei iniziare a farlo e vedere se aiuta a mantenere le cose meglio organizzate.

Quali sono alcune best practice per la denominazione dei rami git?

Modifica: nessuno ha effettivamente suggerito convenzioni di denominazione. Elimina i rami quando ho finito con loro. Mi capita di averne diversi in giro a causa della gestione che adegua costantemente le mie priorità. :) Come esempio del motivo per cui potrei aver bisogno di più di un ramo su un'attività, supponiamo di dover impegnare la prima pietra miliare discreta nell'attività nel repository CVS del gruppo. A quel punto, a causa della mia interazione imperfetta con CVS, avrei eseguito quel commit e quindi ucciso quel ramo. (Ho visto troppa stranezza interagire con CVS se provo a continuare a utilizzare lo stesso ramo in quel punto.)


Sì, probabilmente è bene non tenersi in giro o spingere rami che non sono utili dopo aver finito con loro. A meno che non ci sia una buona ragione per mantenere un ramo di argomento (ad esempio, per consultarlo in un secondo momento), non c'è alcun problema nell'eliminarlo. Git rende la ramificazione facile e un corollario è che puoi finire con molti banali rami in giro che possono essere ripuliti senza molto rumore.
Eric Walker,


2
Per completezza, ci sono alcune sequenze di caratteri che non puoi usare .
Nick Westgate,

18
Deve esserci spazio per questo tipo di domande all'interno della rete StackExchange. Molto fastidioso quando qualcuno fa una buona domanda come questa e poi si chiude per non seguire le regole. Se continua a succedere, ciò dovrebbe probabilmente segnalare la necessità di supportare questo tipo di domande in qualche modo. Solo, questi dovrebbero probabilmente essere implementati all'interno del sito di Overflow perché sono così strettamente correlati alle domande sul tipo di programmazione. Overflow, per me, non è per "domande obiettivamente rispondenti" (troppo specifiche), è "Domande sulla programmazione".
Nick Res

@Wim Usiamo i tasti di emissione jira, combinati con un titolo breve, ad esempio:KEY-1234/allow-users-to-do-smart-stuff
RobAu

Risposte:


938

Ecco alcune convenzioni di denominazione delle filiali che utilizzo e le relative ragioni

Convenzioni di denominazione delle filiali

  1. Usa i token di raggruppamento (parole) all'inizio dei nomi delle filiali.
  2. Definire e utilizzare token di lead brevi per differenziare i rami in modo significativo per il flusso di lavoro.
  3. Usa le barre per separare parti dei nomi delle filiali.
  4. Non utilizzare numeri nudi come parti iniziali.
  5. Evitare nomi descrittivi lunghi per rami di lunga durata.

Token di gruppo

Usa i token di "raggruppamento" davanti ai nomi delle tue filiali.

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

I gruppi possono essere nominati come preferisci per adattarli al tuo flusso di lavoro. Mi piace usare nomi brevi per i miei. Continua a leggere per maggiore chiarezza.

Brevi token ben definiti

Scegli i token brevi in ​​modo che non aggiungano troppo rumore a ciascuno dei nomi delle tue filiali. Io uso questi:

wip       Works in progress; stuff I know won't be finished soon
feat      Feature I'm adding or expanding
bug       Bug fix or experiment
junk      Throwaway branch created to experiment

Ognuno di questi token può essere utilizzato per indicare a quale parte del flusso di lavoro appartiene ogni ramo.

Sembra che tu abbia più rami per diversi cicli di un cambiamento. Non so quali siano i tuoi cicli, ma supponiamo che siano "nuovi", "test" e "verificati". Puoi nominare i tuoi rami con versioni abbreviate di questi tag, scritti sempre allo stesso modo, sia per raggrupparli che per ricordarti in quale fase ti trovi.

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

Puoi dire rapidamente quali rami hanno raggiunto ogni diverso stadio e puoi raggrupparli facilmente usando le opzioni di corrispondenza dei pattern di Git.

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

Usa le barre per separare le parti

Puoi usare quasi tutti i delimitatori che ti piacciono nei nomi delle filiali, ma trovo che le barre siano le più flessibili. Potresti preferire utilizzare trattini o punti. Ma le barre consentono di rinominare i rami quando si spinge o si preleva da / verso un telecomando.

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

Per me, anche le barre funzionano meglio per l'espansione delle schede (completamento del comando) nella mia shell. Il modo in cui l'ho configurato posso cercare rami con diverse sotto-parti digitando i primi caratteri della parte e premendo il tasto TAB. Zsh mi dà quindi un elenco di rami che corrispondono alla parte del token che ho digitato. Funziona con i token precedenti e quelli incorporati.

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell è molto configurabile per il completamento del comando e potrei anche configurarlo per gestire trattini, trattini bassi o punti allo stesso modo. Ma ho scelto di non farlo.)

Ti permette anche di cercare rami in molti comandi git, in questo modo:

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*" 

Avvertenza: come sottolinea Slipp nei commenti, le barre possono causare problemi. Poiché i rami sono implementati come percorsi, non è possibile avere un ramo chiamato "foo" e un altro ramo chiamato "foo / bar". Questo può essere fonte di confusione per i nuovi utenti.

Non usare numeri nudi

Non utilizzare numeri nudi (o numeri esadecimali) come parte dello schema di denominazione delle filiali. All'interno dell'espansione di tabulazione di un nome di riferimento, git può decidere che un numero fa parte di uno sha-1 anziché un nome di ramo. Ad esempio, il mio tracker di problemi nomina i bug con numeri decimali. Nomino i miei rami correlati CRnnnnn piuttosto che semplicemente nnnnn per evitare confusione.

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

Se provassi ad espandere solo 15032, git non sarebbe sicuro se volevo cercare i nomi di SHA-1 o dei rami e le mie scelte sarebbero alquanto limitate.

Evita nomi descrittivi lunghi

I nomi di rami lunghi possono essere molto utili quando si guarda un elenco di rami. Ma può interferire quando si esaminano i registri di una riga decorati poiché i nomi dei rami possono assorbire la maggior parte della singola riga e abbreviare la parte visibile del registro.

D'altra parte, i nomi di rami lunghi possono essere più utili nei "commit di unione" se non li riscrivi abitualmente a mano. Il messaggio di commit di unione predefinito è Merge branch 'branch-name'. Potresti trovare più utile visualizzare i messaggi di unione come Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'anziché semplicemente Merge branch 'fix/CR15032'.


156
Un aspetto negativo dell'utilizzo di un mix di moduli come bug/20574/frabnotz-findered bug/20424è che una volta iniziato senza un token secondario, non è possibile aggiungerne uno in seguito e viceversa. Ad esempio: se si crea un bug/20424ramo, non è possibile creare un bug/20424/additional-fixingramo in un secondo momento (a meno che non si elimini il bug/20424ramo). Allo stesso modo, se bug/20574/frabnotz-finderè già un ramo, non è possibile creare un bug/20574ramo. Tendo a utilizzare un delimitatore non sub-token in casi come questo (ad esempio bug/20574_frabnotz-finder), oppure a scegliere un nome predefinito per il sub-token (ad esempio bug/20424/main).
Slipp D. Thompson,

5
Ha anche il vantaggio di richiedere alcuni strumenti basati su GUI Git per consentire il collasso delle divisioni di token come una visualizzazione dell'elenco di directory. Nell'esempio di cui sopra, si vedrebbe un featuregruppo e un buggruppo, espandibile per mostrare foo, bartag per il primo e una 20574, 20592i gruppi e 20424, 21334i tag per il secondo.
Slipp D. Thompson,

47
Inizierò una campagna per non usare mai le barre nella denominazione di git branch. La ragione di ciò è che se su un elemento della configurazione, ad esempio, si desidera fare riferimento al nome della filiale, ad esempio quando si impacchetta il codice, si desidera fare riferimento al nome della filiale quando si costruisce un uri o un PERCORSO (ad esempio), magari costruendo un urì in uno script bash; avrai difficoltà a costruire l'uri a causa della barra che aggiunge una parte url. Sì, è possibile sostituire la barra, ma mi ci vorrà molto tempo per risolvere.
Adam Spence,

13
È un problema che le barre in avanti abbiano un significato per git in alcuni casi? Ad esempio, in risposta a git branch -a, e ottenere remotes/origin/master, ecc. Quando vedo git parlarmi di un ramo, non uso barre rovesciate e quindi quando ne vedo uno, so che è un riferimento "speciale".
Dogweather,

11
Potresti usare alcuni esempi invece di foo and bar per favore?
Degno 7

329

Un modello di ramificazione Git di successo di Vincent Driessen ha buoni suggerimenti. Una foto è sotto. Se questo modello di diramazione ti piace considerare l' estensione del flusso su git . Altri hanno commentato il flusso

Il modello di Driessen include

  • Un ramo principale, utilizzato solo per il rilascio. Nome tipico master.

  • Un ramo "sviluppo" al largo di quel ramo. È quello usato per la maggior parte dei lavori di linea principale. Comunemente chiamato develop.

  • Molteplici funzioni si dipartono dal ramo di sviluppo. Nome basato sul nome della funzione. Questi verranno riuniti nello sviluppo, non nei rami master o di rilascio.

  • Branch di rilascio per contenere le versioni candidate, con solo correzioni di bug e nessuna nuova funzionalità. Nome tipico rc1.1.

Gli hotfix sono rami di breve durata per i cambiamenti che provengono dal master e andranno al master senza essere coinvolti nel ramo di sviluppo.

inserisci qui la descrizione dell'immagine


129
Tranne il fatto che non affronta davvero la domanda, dal momento che lascia un sacco di convenzioni di denominazione all'utente, specialmente per i rami delle caratteristiche (possono essere "qualsiasi cosa tranne master, sviluppo, rilascio o aggiornamento rapido ")
Brian

1
@Brian Cosa aiuterebbe una convenzione di denominazione delle caratteristiche nel contesto dei problemi che il modello risolve? Non vedo davvero, al momento, come sia davvero utile fare ulteriori distinzioni nelle funzionalità. Forse futuro vs prossimo rilascio, ma è negoziabile e quindi non dovrebbe far parte del nome. Per leggibilità, forse semplicemente anteponendoli con feature- * sarebbe sufficiente. Ti sei alzato votato alcune volte, quindi sono solo curioso di sentire il tuo processo di pensiero ...
Nick Res

2
Sebbene una buona informazione questa risposta affronta la questione del flusso piuttosto che della convenzione di denominazione. Penso che l'OP vorrebbe sapere quali parole reali usare (sostantivi contro verbi), delimitatori, caso ecc.
Caltor

6
Il libro Continuous Delivery (p. 36) sostiene che questo modello è un po 'antitetico all'integrazione continua, ... in sostanza, non è realmente "agile".
Markon,

Questo in realtà non risponde alla domanda che è stata posta. Questo offre informazioni dettagliate sull'integrazione di un flusso di lavoro git specifico in uno sviluppo globale e in una pianificazione delle versioni, tuttavia, l'operatore è alla ricerca di consigli sulle convenzioni su come chiamare realmente le filiali.
Wheeler

56

La mia preferenza personale è quella di eliminare il nome del ramo dopo aver terminato un ramo di argomento.

Invece di provare a usare il nome del ramo per spiegare il significato del ramo, inizio la riga dell'oggetto del messaggio di commit nel primo commit su quel ramo con "Branch:" e includo ulteriori spiegazioni nel corpo del messaggio se l'oggetto non mi dà abbastanza spazio.

Il nome del ramo nel mio uso è puramente una maniglia per fare riferimento a un ramo argomento mentre ci si lavora. Una volta terminato il lavoro sul ramo argomento, mi libero dal nome del ramo, a volte taggando il commit per riferimento futuro.

Ciò rende anche l'output di git branchpiù utile: elenca solo rami di lunga durata e rami di argomenti attivi, non tutti i rami di sempre.


53

Ho mischiato e abbinato diversi schemi che ho visto e basato sugli strumenti che sto usando.
Quindi il mio nome di filiale completato sarebbe:

Nome / funzione / numero-Tracker-numero / breve descrizione

che si tradurrebbe in:

mike / blogs / RSSI-12 / logo-fix

Le parti sono separate da barre in avanti perché vengono interpretate come cartelle in SourceTree per una facile organizzazione. Utilizziamo Jira per il rilevamento dei problemi, quindi includere il numero semplifica la ricerca nel sistema. Includere quel numero lo rende anche ricercabile quando si cerca di trovare quel problema all'interno di Github quando si tenta di inviare una richiesta pull.


Sono lo stesso, tranne il numero di bug / funzione nel messaggio di commit (per GitHub -> integrazione di Pivotal Tracker).
Leo,

Mi chiedo cosa significhi RSSI.
Renshuki,

@renshuki è solo una chiave di progetto Jira generica. Qualunque sia il tracker dei problemi che usi, inserisci l'ID del biglietto
MikeG

@MikeG grazie per la precisione!
Renshuki,

3
Uso lo stesso tranne che passo il numero del problema insieme alla descrizione:name/feature/issue-tracker-number-short-description
lephleg,

22

Perché ci vogliono tre rami / fusioni per ogni attività? Puoi spiegare di più al riguardo?

Se si utilizza un sistema di tracciamento dei bug, è possibile utilizzare il numero di bug come parte del nome del ramo. Ciò manterrà i nomi dei rami univoci e potrai prefissarli con una o due parole brevi e descrittive per renderli leggibili dall'uomo, come "ResizeWindow-43523". Aiuta anche a semplificare le cose quando vai a ripulire i rami, poiché puoi cercare il bug associato. Questo è il modo in cui di solito nome i miei rami.

Poiché alla fine questi rami vengono nuovamente uniti in master, dovresti essere sicuro di eliminarli dopo l'unione. A meno che non ti stia fondendo --squash, l'intera storia del ramo esisterà comunque se mai ne avessi bisogno.


12

Nota, come illustrato nel commit e703d7 o commit b6c2a0d (marzo 2014), ora parte di Git 2.0, troverai un'altra convenzione di denominazione (che puoi applicare alle filiali).

"Quando devi usare lo spazio, usa il trattino" è uno strano modo di dire che non devi usare uno spazio.
Poiché è più comune che le descrizioni della riga di comando utilizzino più parole tratteggiate, non si desidera nemmeno utilizzare spazi in questi luoghi.

Il nome di un ramo non può avere spazio (vedi " Quali caratteri sono illegali nel nome di un ramo? " E nella git check-ref-formatpagina man ).

Quindi per ogni nome di ramo che sarebbe rappresentato da un'espressione multi-parola, usare una ' -' (trattino) come separatore è una buona idea.


7

Seguendo il suggerimento di Farktronix, abbiamo usato i numeri dei biglietti Jira per simili in mercurial e sto programmando di continuare a usarli per i rami git. Ma penso che il numero del biglietto stesso sia probabilmente abbastanza unico. Mentre potrebbe essere utile avere una parola descrittiva nel nome del ramo come annotato farktronix, se si passa da un ramo all'altro abbastanza spesso, probabilmente si vuole meno scrivere. Quindi, se hai bisogno di conoscere il nome della filiale, cerca in Jira le parole chiave associate nel biglietto se non lo conosci. Inoltre, dovresti includere il numero del biglietto in ogni commento.

Se il tuo ramo rappresenta una versione, sembra che la convenzione comune debba usare il formato xxx (esempio: "1.0.0") per i nomi dei rami e vx.xx (esempio "v1.0.0") per i nomi dei tag (per evitare conflitti) . Vedi anche: is-there-an-standard-naming-convention-for-git-tags


1
C'è un problema con i conflitti? Se l'intento è che un v1.2.4ramo alla fine porti a un end-point con un v1.2.4tag (sono corretto nel supporre che questa sia la situazione in cui si nominano sia rami che tag dopo una versione) , allora importa? Il tag può ancora essere raggiunto in refs/tags/v1.2.4e il ramo in refs/heads/v1.2.4, e sembra che Git preferirà il nome del tag quando è ambiguo (con un avviso).
Slipp D. Thompson,

1
Per l'esempio di versione, come ho detto nella mia risposta, una pratica suggerita è quella di aggiungere il prefisso "v" per i nomi dei tag, non per i rami. Evita l'ambiguità se puoi evitare errori di comunicazione e perché potrebbe causare problemi lungo la strada migrando verso qualsiasi VCS più recente e più recente.
Gary S. Weaver,

2
Di recente ho lavorato con un repository in cui abbiamo chiuso ogni ramo di versione con un tag con lo stesso nome. Ha funzionato molto bene perché non c'è poca o nessuna ambiguità (il tag punta all'ultimo commit sul ramo corrispondente nella maggior parte dei casi), e quando potrebbe esserci, Git "fa la cosa giusta" (con un avvertimento). Lo preferisco perché se qualcuno commette un errore alla testa e si impegna ulteriormente in un ramo chiuso, Git continuerà a scegliere il tag, che è l'intento. L'ambiguità può semplificare le cose quando il sistema ha tutto sotto controllo e l'intento è chiaro.
Slipp D. Thompson,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.