Git Bisect ha trovato il commit buggato. Ora cosa?

0

Ho visto post sul blog che spiegano come eseguire Git bisect, ma come correggere il bug, eseguire nuovamente il commit e mantenere il resto della cronologia dei commit?

Un vero problema che ho affrontato nel mio progetto era come questo (l'immagine è solo un'approssimazione):

Ho contrassegnato il commit più in alto in bad e il commit in basso in good . Alcuni dei commit sotto Buggy commit A erano buoni commit, perché da qualche parte nel mezzo, avevo commentato il codice che rendeva Bad commit B un commit errato. Quindi, naturalmente, git bisect mi ha portato prima a Buggy commit B .

Ho corretto il bug e quando ho provato a eseguire il commit, volevo che le righe di codice modificate venissero applicate allo stesso Buggy commit B commit. Ma ho scoperto che:

  1. Git crea sempre un nuovo commit per questo
  2. Ho ricevuto l'errore detached head :

    HEAD detached at b855e36 Changes not staged for commit:
    modified:  main.cpp
    

Ora cosa faccio?

Crea un nuovo ramo (chiamiamolo fixedit ) e commetti questo codice corretto? Se lo faccio, allora cosa succede a tutti gli altri commit sopra di esso? Devo fare un rebase (mai fatto prima) del commit sopra Buggy commit B e mettere l'intera linea di commit sul nuovo ramo fixedit ?

Preferirei che mi fosse solo permesso di modificare il commit esistente e l'intero albero rimanesse così com'è, ma poi dovrei passare a tutti i commit superiori a Buggy commit B e correggere la linea buggy in tutti quei commit. Questo non ha senso. Quindi, come si risolvono i bug e si conserva la cronologia dei commit correttamente?

UPDATE:

Quindi faccio un git bisect reset e corrego il codice sul commit più in alto (perché so quale riga di Buggy commit B ha introdotto il bug)?

Come ho detto prima, il codice che ha causato Buggy commit B è stato commentato in uno dei commit poco prima di Buggy commit A .

  1. Quindi quando nel mio commit più alto vedo che la riga è commentata, mi rendo conto che il bug è da qualche altra parte.
  2. Durante il primo bisect, dal momento che uno dei commit tra A e B è stato contrassegnato come buono, lo sceglierei come buon commit per il mio secondo tentativo Git bisect, e il più recente commit come bad commit e poi continuare con Git bisect. Questo mi porterebbe a Buggy commit A .
  3. Poi farei un git bisect reset e correggi le linee di codice nel codice più in alto e poi eseguo il commit.

Ok; ciò ha senso. Grazie: -)

    
posta Nav 16.01.2016 - 14:14
fonte

1 risposta

13

Non aggiusti quel commit. È un dato di fatto che il bug è stato introdotto, e va bene. L'hai trovato adesso e sai come aggiustarlo, bene! Come con qualsiasi altra correzione di bug, si crea un commit nuovo sopra lo stato corrente del progetto. Questo conserva la cronologia e corregge il bug. Riscrivere la cronologia in modo che il bug non sia mai esistito è inutile, persino pericoloso:

  • Non ha alcun vantaggio. Voglio dire, potresti far finta che il bug non sia mai esistito, ma se hai dovuto bisecare allora il bug probabilmente esisteva per un po 'e veniva riscontrato dagli utenti. Riscrivere la cronologia git non lo annulla. Renderà più difficile capire cosa è successo.
  • Se il codice in corrispondenza della posizione del bug fix è cambiato in altri modi da quando è stato introdotto il bug (che sembra essere il caso), non è possibile correggere il bug nel commit B e rebase tutti i successivi commit su quello. Dovresti risolvere manualmente i conflitti, il che richiede tempo e rischia di introdurre nuovi bug.
  • Si applicano le solite preoccupazioni in merito alla cronologia della riscrittura. La ridefinizione di così tanti commit pubblicizzati causerà problemi a tutti coloro che hanno un lavoro basato su questi commit (ad esempio se hanno un branch basato su un commit dopo B, non saranno in grado di unire facilmente questo ramo). Più in generale, interrompe tutti i riferimenti a commit specifici (che arrivano dopo B), poiché tutti gli hash cambiano.
risposta data 16.01.2016 - 14:30
fonte

Leggi altre domande sui tag