Convenzione di ramificazione di bug Git

Question

Convenzione di ramificazione di bug Git

#1 da (4 voti)

7

Ho seguito il riuscito modello di ramificazione di Git per la maggior parte del mio sviluppo . Mi chiedo ancora se il modo in cui gestisco i bug ticket sia corretto.

Il mio flusso di lavoro corrente: una volta accettato un bug ticket, eseguirò un git checkout -b bug/{ticket_number} , creerò un singolo commit come una correzione e poi il checkout svilupperà e farà un git merge --no-ff .

Mi piacerebbe sentire dalle esperienze degli altri se sto abusando o meno dell'opzione --no-ff in questo caso. Se lo sono, qualcuno potrebbe suggerire un approccio migliore?

git branching

posta flumpb 07.06.2012 - 16:54

fonte

1 risposta

Leggi altre domande sui tag git branching

Strategie di paging: token di pagina o indice di salto / inizio Linguaggi di programmazione, linguaggi posizionali e lingue naturali

score 4 · Accepted Answer

Non hai bisogno di fare tutto il tuo lavoro come un singolo commit; è possibile eseguire il commit più volte e schiacciare i commit quando si uniscono nuovamente al ramo originale (che è il comportamento di unione predefinito). Se il bug è significativo, potrebbe essere utile.

Inoltre, se il ramo è aperto per un lungo periodo, potresti voler rebase del ramo (in pratica, ricrea il ramo da una versione root più recente e applica nuovamente le modifiche); questo aggiornerà il ramo con le modifiche a monte e sarai in grado di verificare se qualche modifica a monte ha infranto il tuo bugfix.

Dopo aver spinto il ramo a monte, comunque (nel caso lo facciate), non è raccomandato rebasing. Puoi creare un nuovo ramo dalla radice e unire il tuo vecchio ramo al nuovo. Questo sembra funzionare, ma non sono sicuro che sia corretto.