En ändring har redan hamnat i den gemensamma grenen, och nu har en bugg följt med ut. Oftast är git revert det säkrare sättet att backa ändringen, men resultatet beror på vad som har ändrats sedan committen skapades.
Revert backar ändringen med en ny commit
- Ångra en commit: kör
git revert. - Ändra inte historiken: revert skapar en ny commit som motverkar den valda ändringen.
- Kontrollera resultatet: granska diffen innan du pushar, särskilt om senare commits ändrat samma kod.
- Merge commit: ange huvudföräldern med
-m, annars saknar Git ett nödvändigt val.
En revert lägger till en commit, den raderar inte den gamla
Commithistoriken kan se oförändrad ut vid första anblicken, men Git skriver inte om den tidigare committen. Kommandot skapar en ny commit med motsatta ändringar, så felet går att backa utan att sudda ut delad historik. ([git-scm.com](https://git-scm.com/docs/git-revert.html?utm_source=openai))
Jag tycker att det är den tydligaste vägen när committen redan har pushats eller ingår i en gren som andra hämtar. Om ändringen däremot bara finns lokalt och ingen annan bygger vidare på den kan git reset passa bättre, eftersom det flyttar grenens pekare och därmed ändrar historiken.
Hitta rätt commit och granska vad som kommer att vändas
En kort hash räcker vanligtvis för att peka ut committen, men gissa inte utifrån en gammal terminalrad. Börja med git log --oneline och kontrollera meddelandet och hashvärdet mot ändringen du vill ångra.
git log --oneline
git show --stat
git revert Den tredje raden startar själva återställningen och öppnar normalt editorn för commitmeddelandet. Git rekommenderar att du förklarar varför ändringen backas, eftersom meddelandet då hjälper nästa person att förstå historiken. ([git-scm.com](https://git-scm.com/docs/git-revert.html?utm_source=openai))
Om du vill granska ändringarna innan en ny commit skapas kan du använda git revert --no-commit . Då hamnar den omvända ändringen i arbetskatalogen och index, och du kan kontrollera diffen innan du själv kör git commit.
Senare ändringar kan göra en gammal revert ofullständig
En commit kan ha ändrat samma kod som en senare commit. Då går det inte att räkna med att revert återställer filen till ett tidigare tillstånd rakt av; Git försöker vända just den valda committen, och följdändringar kan finnas kvar eller orsaka konflikter.
| Situation | Möjlig följd | Gör så här |
|---|---|---|
| Committen ändrade kod som senare ändrats igen | Senare arbete kan bli kvar eller ge en konflikt | Granska git diff och testa berörda funktioner |
| Git markerar konflikt under revert | Filer kräver manuell lösning | Redigera konflikterna, stagea filerna och kör git revert --continue |
| Du vill avbryta en pågående revert | Git återgår till läget före operationen | Kör git revert --abort |
När konflikter uppstår är det frestande att välja ena sidan i varje fil utan att kontrollera sammanhanget. Jag skulle i stället läsa konfliktblocken tillsammans med den ursprungliga committen och de senare ändringarna, eftersom en automatisk lösning kan ta bort fungerande arbete som tillkom efteråt.
En merge commit kräver att du väljer vilken förälder som ska behållas
En merge commit har flera föräldrar, så Git kan inte veta vilken bas du vill utgå från. Med -m 1 väljer du den första föräldern som huvudlinje, vilket ofta motsvarar grenen som tog emot mergningen, men kontrollera grafen innan du kör kommandot.
git show --no-patch --pretty=raw
git revert -m 1 Valet får följder för framtida mergningar: Git behandlar fortfarande de inmergade committerna som en del av historiken, även efter att deras ändringar har backats. Om arbetet ska tas in igen senare kan det därför krävas att revert-committen själv ångras eller att nya ändringar skapas. ([git-scm.com](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging?utm_source=openai))
Välj revert när andra redan delar grenen
En enkel beslutsregel gör valet mindre rörigt: pushad eller delad commit, välj normalt revert; opushad lokal commit som ska tas bort ur historiken, överväg reset. GitHub beskriver samma skillnad för delat arbete: revert backar ändringen utan att störa historiken för andra bidragsgivare. ([docs.github.com](https://docs.github.com/en/desktop/managing-commits/resetting-to-a-commit-in-github-desktop?utm_source=openai))
Exempel: en felaktig ändring med hash abc1234 ligger i en gemensam gren, och två senare commits har redan lagts ovanpå. Kör git revert abc1234, granska den nya diffen och testa resultatet; använd inte git reset till den gamla punkten, eftersom det skulle flytta grenen bakåt och riskera att ta bort de senare commits ur den delade historiken.
Gör återställningen begriplig för nästa person
En revert löser kodproblemet först när den omvända ändringen har granskats och verifierats. Skriv ett commitmeddelande som anger orsaken, kör relevanta tester och låt gärna ändringen gå genom samma pull request-flöde som annat arbete.
För en redan publicerad commit är mitt val alltså revert med en tydlig granskning av diffen. Då lämnas en spårbar förklaring i historiken, även om senare ändringar innebär att resultatet behöver mer än ett kommando.