Come posso riparare facilmente un commit passato?

Ho appena letto la modifica di un singolo file in un commit passato in git, ma sfortunatamente la soluzione accettata "riordina" i commit, che non è quello che voglio. Quindi ecco la mia domanda:

Di tanto in tanto, noto un bug nel mio codice mentre lavoro su una funzionalità (non correlata). Una rapida git blamequindi rivela che il bug è stato introdotto alcuni commit fa (mi impegno parecchio, quindi di solito non è il commit più recente che ha introdotto il bug). A questo punto, di solito faccio questo:

git stash                      # temporarily put my work aside
git rebase -i <bad_commit>~1   # rebase one step before the bad commit
                               # mark broken commit for editing
vim <affected_sources>         # fix the bug
git add <affected_sources>     # stage fixes
git commit -C <bad_commit>     # commit fixes using same log message as before
git rebase --continue          # base all later changes onto this

Tuttavia, questo accade così spesso che la sequenza di cui sopra sta diventando fastidiosa. Soprattutto il "rebase interattivo" è noioso. C'è qualche scorciatoia per la sequenza di cui sopra, che mi consente di modificare un commit arbitrario in passato con le modifiche graduali? Sono perfettamente consapevole che questo cambia la storia, ma faccio errori così spesso che mi piacerebbe davvero avere qualcosa di simile

vim <affected_sources>             # fix bug
git add -p <affected_sources>      # Mark my 'fixup' hungs for staging
git fixup <bad_commit>             # amend the specified commit with staged changes,
                                   # rebase any successors of bad commit on rewritten 
                                   # commit.

Forse uno script intelligente in grado di riscrivere i commit utilizzando strumenti idraulici o giù di lì?

RISPOSTA AGGIORNATA

Tempo fa è --fixupstato aggiunto un nuovo argomento al git commitquale è possibile utilizzare per costruire un commit con un messaggio di log adatto git rebase --interactive --autosquash. Quindi il modo più semplice per correggere un commit passato è ora:

$ git add ...                           # Stage a fix
$ git commit --fixup=a0b1c2d3           # Perform the commit to fix broken a0b1c2d3
$ git rebase -i --autosquash a0b1c2d3~1 # Now merge fixup commit into broken commit

RISPOSTA ORIGINALE

Ecco un piccolo script Python che ho scritto qualche tempo fa che implementa questa git fixuplogica che speravo nella mia domanda originale. Lo script presume che tu abbia messo in scena alcune modifiche e quindi applica tali modifiche al commit specificato.

NOTA : questo script è specifico di Windows; cerca git.exee imposta la GIT_EDITORvariabile d'ambiente usando set. Regola questo come necessario per altri sistemi operativi.

Usando questo script posso implementare precisamente il flusso di lavoro 'fix broken sources, stage fixup, run git fixup' che ho richiesto:

#!/usr/bin/env python
from subprocess import call
import sys

# Taken from http://stackoverflow.com/questions/377017/test-if-executable-exists-in python
def which(program):
    import os
    def is_exe(fpath):
        return os.path.exists(fpath) and os.access(fpath, os.X_OK)

    fpath, fname = os.path.split(program)
    if fpath:
        if is_exe(program):
            return program
    else:
        for path in os.environ["PATH"].split(os.pathsep):
            exe_file = os.path.join(path, program)
            if is_exe(exe_file):
                return exe_file

    return None

if len(sys.argv) != 2:
    print "Usage: git fixup <commit>"
    sys.exit(1)

git = which("git.exe")
if not git:
    print "git-fixup: failed to locate git executable"
    sys.exit(2)

broken_commit = sys.argv[1]
if call([git, "rev-parse", "--verify", "--quiet", broken_commit]) != 0:
    print "git-fixup: %s is not a valid commit" % broken_commit
    sys.exit(3)

if call([git, "diff", "--staged", "--quiet"]) == 0:
    print "git-fixup: cannot fixup past commit; no fix staged."
    sys.exit(4)

if call([git, "diff", "--quiet"]) != 0:
    print "git-fixup: cannot fixup past commit; working directory must be clean."
    sys.exit(5)

call([git, "commit", "--fixup=" + broken_commit])
call(["set", "GIT_EDITOR=true", "&&", git, "rebase", "-i", "--autosquash", broken_commit + "~1"], shell=True)

Quello che faccio è:

git add ... # Aggiungi la correzione.
git commit # Commesso, ma nel posto sbagliato.
git rebase -i HEAD ~ 5 # Esamina gli ultimi 5 commit per il rebase.

Il tuo editor si aprirà con un elenco degli ultimi 5 commit, pronto per essere immischiato. Modificare:

pick 08e833c Buon cambiamento 1.
pick 9134ac9 Buon cambiamento 2.
scegli 5adda55 Cattivo cambiamento!
pick 400bce4 Buon cambiamento 3.
pick 2bc82n1 Correzione di un brutto cambiamento.

...per:

pick 08e833c Buon cambiamento 1.
pick 9134ac9 Buon cambiamento 2.
scegli 5adda55 Cattivo cambiamento!
f 2bc82n1 Correzione di una modifica errata. # Sposta in alto e cambia 'pick' in 'f' per 'fixup'.
pick 400bce4 Buon cambiamento 3.

Salva ed esci dall'editor e la correzione verrà nuovamente compressa nel commit a cui appartiene.

Dopo averlo fatto alcune volte, lo farai in pochi secondi nel sonno. Il rebase interattivo è la caratteristica che mi ha davvero venduto su git. È incredibilmente utile per questo e altro ...

Un po 'in ritardo per la festa, ma ecco una soluzione che funziona come immaginava l'autore.

Aggiungi questo al tuo .gitconfig:

[alias]
    fixup = "!sh -c '(git diff-files --quiet || (echo Unstaged changes, please commit or stash with --keep-index; exit 1)) && COMMIT=$(git rev-parse $1) && git commit --fixup=$COMMIT && git rebase -i --autosquash $COMMIT~1' -"

Utilizzo di esempio:

git add -p
git fixup HEAD~5

Tuttavia, se hai modifiche non organizzate, devi nasconderle prima del rebase.

git add -p
git stash --keep-index
git fixup HEAD~5
git stash pop

È possibile modificare l'alias in modo che venga nascosto automaticamente, invece di fornire un avviso. Tuttavia, se la correzione non si applica in modo pulito, sarà necessario aprire manualmente lo stash dopo aver risolto i conflitti. Fare sia il salvataggio che lo scoppio manualmente sembra più coerente e meno confuso.

Per correggere un commit:

git commit --fixup a0b1c2d3 .
git rebase --autosquash -i HEAD~2

dove a0b1c2d3 è il commit che si desidera correggere e dove 2 è il numero di commit incollati +1 che si desidera modificare.

Nota: git rebase --autosquash senza -i non ha funzionato ma con -i ha funzionato, il che è strano.

AGGIORNAMENTO: una versione più pulita dello script ora può essere trovata qui: https://github.com/deiwin/git-dotfiles/blob/docs/bin/git-fixup .

Ho cercato qualcosa di simile. Questo script Python sembra troppo complicato, quindi ho messo insieme la mia soluzione:

Innanzitutto, i miei alias git sono così (presi in prestito da qui ):

[alias]
  fixup = !sh -c 'git commit --fixup=$1' -
  squash = !sh -c 'git commit --squash=$1' -
  ri = rebase --interactive --autosquash

Ora la funzione bash diventa abbastanza semplice:

function gf {
  if [ $# -eq 1 ]
  then
    if [[ "$1" == HEAD* ]]
    then
      git add -A; git fixup $1; git ri $1~2
    else
      git add -A; git fixup $1; git ri $1~1
    fi
  else
    echo "Usage: gf <commit-ref> "
  fi
}

Questo codice innanzitutto mette in scena tutte le modifiche correnti (puoi rimuovere questa parte, se desideri organizzare i file da solo). Quindi crea la correzione (si può usare anche squash, se è quello che ti serve) commit. Dopodiché avvia un rebase interattivo con il --autosquashflag sul genitore del commit che dai come argomento. Questo aprirà il tuo editor di testo configurato, in modo da poter verificare che tutto sia come ti aspetti e semplicemente chiudendo l'editor terminerà il processo.

La if [[ "$1" == HEAD* ]]parte (presa in prestito da qui ) viene utilizzata, perché se si utilizza, ad esempio, HEAD ~ 2 come riferimento per il commit (il commit con cui si desidera correggere le modifiche correnti), HEAD verrà spostato dopo che è stato creato il commit di correzione e dovresti usare HEAD ~ 3 per fare riferimento allo stesso commit.

Puoi evitare la fase interattiva utilizzando un editor "nullo":

$ EDITOR=true git rebase --autosquash -i ...

Questo userà /bin/truecome editor, invece di /usr/bin/vim. Accetta sempre qualsiasi cosa suggerisca git, senza chiedere conferma.

Quello che mi ha davvero infastidito del flusso di lavoro di riparazione è stato il fatto che dovevo capire da solo in quale impegno volevo schiacciare il cambiamento ogni volta. Ho creato un comando "git fixup" che aiuta con questo.

Questo comando crea commit di correzione, con la magia aggiunta che utilizza git-deps per trovare automaticamente il commit pertinente, quindi il flusso di lavoro spesso si riduce a:

# discover and fix typo in a previously committed change
git add -p # stage only typo fix
git fixup

# at some later point squash all the fixup commits that came up
git rebase --autosquash master

Questo funziona solo se le modifiche staged possono essere attribuite in modo inequivocabile a un particolare commit sull'albero di lavoro (tra master e HEAD). Trovo che questo sia il caso molto spesso per il tipo di piccole modifiche per cui lo uso, ad esempio errori di battitura nei commenti o nomi di metodi appena introdotti (o rinominati). In caso contrario, verrà visualizzato almeno un elenco di commit candidati.

Lo uso molto nel mio flusso di lavoro quotidiano, per integrare rapidamente piccole modifiche a linee precedentemente modificate nei commit nel mio ramo di lavoro. La sceneggiatura non è così bella come potrebbe essere, ed è scritta in zsh, ma ha svolto il lavoro abbastanza bene per me da un bel po 'di tempo ora che non ho mai sentito il bisogno di riscriverla:

https://github.com/Valodim/git-fixup

È possibile creare una correzione per un particolare file utilizzando questo alias.

[alias]
...
# fixup for a file, using the commit where it was last modified
fixup-file = "!sh -c '\
        [ $(git diff          --numstat $1 | wc -l) -eq 1 ] && git add $1 && \
        [ $(git diff --cached --numstat $1 | wc -l) -eq 1 ] || (echo No changes staged. ; exit 1) && \
        COMMIT=$(git log -n 1 --pretty=format:"%H" $1) && \
            git commit --fixup=$COMMIT && \
            git rebase -i --autosquash $COMMIT~1' -"

Se hai apportato alcune modifiche myfile.txtma non desideri inserirle in un nuovo commit, git fixup-file myfile.txtcreerà un fixup!per il commit in cui è myfile.txtstato modificato l'ultima volta, e poi lo farà rebase --autosquash.

commit --fixupe rebase --autosquashsono fantastici, ma non fanno abbastanza. Quando ho una sequenza di commit A-B-Ce scrivo altre modifiche nel mio albero di lavoro che appartengono a uno o più di quei commit esistenti, devo guardare manualmente la cronologia, decidere quali modifiche appartengono a quali commit, metterli in scena e creare il fixup!impegna. Ma git ha già accesso a informazioni sufficienti per essere in grado di fare tutto ciò per me, quindi ho scritto uno script Perl che fa proprio questo.

Per ogni pezzo nello git diffscript usa git blameper trovare il commit che ha toccato per ultimo le righe pertinenti e chiama git commit --fixupper scrivere i fixup!commit appropriati , essenzialmente facendo la stessa cosa che stavo facendo manualmente prima.

Se lo trovi utile, sentiti libero di migliorarlo e ripeterlo e forse un giorno avremo una funzionalità del genere git appropriato. Mi piacerebbe vedere uno strumento in grado di capire come dovrebbe essere risolto un conflitto di unione quando è stato introdotto da un rebase interattivo.

Ho scritto una piccola funzione di shell chiamata gcfper eseguire automaticamente il commit di correzione e il rebase:

$ git add -p

  ... select hunks for the patch with y/n ...

$ gcf <earlier_commit_id>

  That commits the fixup and does the rebase.  Done!  You can get back to coding.

Ad esempio, puoi patchare il secondo commit prima dell'ultimo con: gcf HEAD~~

Ecco la funzione . Puoi incollarlo nel tuo file~/.bashrc

git_commit_immediate_fixup() {
  local commit_to_amend="$1"
  if [ -z "$commit_to_amend" ]; then
    echo "You must provide a commit to fixup!"; return 1
  fi

  # Get a static commit ref in case the commit is something relative like HEAD~
  commit_to_amend="$(git rev-parse "${commit_to_amend}")" || return 2

  #echo ">> Committing"
  git commit --no-verify --fixup "${commit_to_amend}" || return 3

  #echo ">> Performing rebase"
  EDITOR=true git rebase --interactive --autosquash --autostash \
                --rebase-merges --no-fork-point "${commit_to_amend}~"
}

alias gcf='git_commit_immediate_fixup'

Utilizza --autostash per nascondere e visualizzare eventuali modifiche non salvate, se necessario.

--autosquashrichiede un --interactiverebase, ma evitiamo l'interazione usando un dummy EDITOR.

--no-fork-pointprotegge i commit dall'essere rilasciati silenziosamente in rare situazioni (quando hai biforcato un nuovo ramo e qualcuno ha già ribasato i commit passati).

Non sono a conoscenza di un modo automatizzato, ma ecco una soluzione che potrebbe essere più facile da botizzare dall'uomo:

git stash
# write the patch
git add -p <file>
git commit -m"whatever"   # message doesn't matter, will be replaced via 'fixup'
git rebase -i <bad-commit-id>~1
# now cut&paste the "whatever" line from the bottom to the second line
# (i.e. below <bad-commit>) and change its 'pick' into 'fixup'
# -> the fix commit will be merged into the <bad-commit> without changing the
# commit message
git stash pop

Consiglierei https://github.com/tummychow/git-absorb :

Piazzola ascensore

Hai un ramo di funzionalità con pochi commit. Il tuo compagno di squadra ha esaminato il ramo e ha segnalato alcuni bug. Hai correzioni per i bug, ma non vuoi inserirli tutti in un commit opaco che dice correzioni, perché credi nei commit atomici. Invece di trovare manualmente SHA di commit per git commit --fixupo eseguire un rebase interattivo manuale, fai questo:

• git add $FILES_YOU_FIXED

• git absorb --and-rebase

• o: git rebase -i --autosquash master

git absorbidentificherà automaticamente quali commit sono sicuri da modificare e quali modifiche indicizzate appartengono a ciascuno di questi commit. Quindi scriverà fixup! si impegna per ciascuna di queste modifiche. Puoi controllarne l'output manualmente se non ti fidi, quindi piegare le correzioni nel tuo ramo delle funzionalità con la funzionalità autosquash integrata di git.