Pro e contro della ramificazione durante la correzione del vecchio codice

Question

Pro e contro della ramificazione durante la correzione del vecchio codice

#1 da (10 voti)
#2 da (0 voti)

7

A volte scopro che un commit che ho fatto due mesi fa aveva un bug. Quindi scrivo una correzione per il bug, ma poi devo sceglierne uno in questi modi:

Posso eseguire il commit della correzione direttamente sul ramo aggiornato principale (il trunk).
Posso usare un ramo al punto del commit buggy originale e commettere la correzione immediatamente dopo. Quindi unisco il ramo nel bagagliaio.

(Questo approccio è talvolta consigliato se il bug è stato creato su un "ramo di funzionalità" esistente.)
(carattere jolly) Potrei usare --fixup per contrassegnare l'associazione, ma non potrò rebase perché invariabilmente la cronologia è già stata condivisa.

Riesco a vedere alcuni pro e contro con ogni approccio, ma mi chiedo se gli utenti esperti abbiano più cose da condividere di quanto io possa immaginare.

In breve, la mia domanda è: qualcuna delle organizzazioni ritiene che l'approccio n. 2 sia sufficientemente utile da adottarlo come standard?

(Al di fuori del caso di mantenere una versione precedente, dove sarebbe probabilmente la scelta più ovvia per risolvere il vecchio ramo di rilascio e quindi unire le versioni successive e il trunk, quando possibile.)

git version-control idioms

posta joeytwiddle 17.12.2016 - 07:12

fonte

2 risposte

Leggi altre domande sui tag git version-control idioms

Argomenti a supporto della transizione organizzativa allo sviluppo di Scala Mercurial ospitato con gli strumenti di gestione dei progetti

score 10 · Answer 1

La mia comprensione è che nel tuo scenario, la funzione è stata completata, il ramo unito e una versione rilasciata?

Se è così, allora non c'è motivo o beneficio per riscrivere la cronologia. Questa è una correzione di bug che non fa parte del tuo cambio di funzionalità. Quindi, semplicemente un nuovo ramo per correggere il bug. Non associarlo nel repository direttamente con il ramo della funzione originale: puoi utilizzare qualsiasi strumento di tracciamento dei bug e di pianificazione del progetto per creare tale associazione.

Ovviamente non solo modificare e spingere il ramo principale, a meno che non si stia seguendo un processo aziendale in cui ciò è considerato OK (forse una sorta di hot fix, in cui si esegue una coppia di programmazione o di revisione sullo schermo prima del commit). / p>

La funzionalità originale e la correzione di bug sono eventi separati nella cronologia del progetto. Trattali esplicitamente come tali, c'è poco o nessun beneficio nel modificarli per qualche preoccupazione di ordine per associazione. Dopotutto, quasi tutti i bug nell'applicazione hanno questa storia esatta: saranno stati introdotti come parte di alcune modifiche pianificate e risolti successivamente quando sono stati scoperti.

score 0 · Answer 2

Op qui, non volendo inquinare la domanda con i miei pensieri attuali.

Ecco i pro che posso concepire per il biforcarsi (supportando l'approccio numero 2):

Abbiamo associato la correzione con il commit originale, perché viene immediatamente dopo. Potrebbe essere più facile in futuro vedere questa associazione.
Ora posso, se lo desidero, tornare a qualsiasi punto della cronologia intermedia e unire in questo ramo per correggere il bug e nient'altro. (Questo potrebbe essere utile per rimuovere le complicazioni di questo bug durante la bisecatura, anche se con avvertimenti.)
Se non forzo, tendo a lasciare l'ID del commit buggy originale nel messaggio del commit della correzione. Quindi c'è almeno un'associazione esplicita, ma sicuramente è meglio creare un'associazione implicita usando la propria storia di git.
Questo approccio non sarà sempre banale: a volte può causare un conflitto di fusione.

E qui ci sono alcuni svantaggi per il biforcarsi (supportando l'approccio numero 1 o 3):

Guardando il grafico della cronologia git, vedremmo ora un arco lungo che arriva dal commit originale fino al momento attuale, quando viene unito al trunk. Se utilizziamo spesso questo approccio, la nostra cronologia diventerà molto ampia con rami ! Ma forse questo dovrebbe essere considerato non un problema, ma una funzionalità.
Il forking non direttamente aiuta ad evitare questo bug durante la bisecatura. Anche se abbiamo un ramo che ha risolto il bug originale senza tutti i commit intermedi, in realtà non entra nel trunk fino al presente.

Infine alcuni pensieri sull'approccio numero 3, anche se probabilmente è un non-antipasto:

L'utilizzo di --fixup è implicito, in quanto git comprende l'associazione. È chiaro e un po 'standardizzato.
Tuttavia, non penso che questo fosse lo scopo originale di --fixup .
Si potrebbe obiettare che potrebbe causare confusione in futuro: rebase --autosquash potrebbe un giorno provare a spostare quel commit indietro nella cronologia. Ma sospetto che non sia un problema, dal momento che nessuno dovrebbe provare a rebase nella cronologia condivisa, poiché potrebbe causare molti altri problemi.