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

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.)

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'.

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.

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.

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.

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.

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.

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