Spåra fel och återställ ändringar säkert

↑

CLI-exempel märkta Bash fungerar i Git Bash på Windows 10 och Windows 11 eller Bash på Linux, med Git installerat. Bash-tilldelningar som DEFAULT_BRANCH=main är kommandotolkens syntax; kör exemplen i Git Bash i stället för att klistra in dem i PowerShell eller Kommandotolken.

Syftet med felsökning är inte att hitta en syndabock, utan att identifiera vilken ändring som förändrade beteendet, förstå sammanhanget och rätta felet med minsta möjliga risk. Börja med symptomet: första felande version, reproduktionssteg, miljö och förväntat resultat. Notera exakt vilken commit som körs i produktion.

Öppna History, välj en commit och granska dess ändringar. På GitHub kan du sedan följa länkar till pull request och ärende. Desktop räcker för grundläggande inspektion och vissa återställningar, men avancerad sökning och bisect görs enklare i terminalen.

git status --short --branch
git log --oneline --decorate --graph -20
git log -- path/to/file.cs
git blame -L 15,35 -- path/to/file.cs
git show --stat COMMIT_HASH

Byt ut filvägar och commit-ID:n. git blame visar vilken commit som senast ändrade en rad. Det bevisar inte vem som orsakade ett fel; granska även historiken och pull requesten.

Hitta den första felande commiten med bisect

git bisect använder en binärsökningsliknande metod genom historiken. Du behöver en känd fungerande commit, en känd felande commit och ett tillförlitligt test. Resultatet pekar på en misstänkt commit som måste undersökas.

# Arbeta i en ren klon eller separat worktree.
git bisect start
git bisect bad BAD_COMMIT
git bisect good GOOD_COMMIT
# Kör samma reproducerbara test för varje utcheckad commit.
git bisect good    # eller: git bisect bad
git bisect reset   # återgå till ursprunglig checkout

GitHub Desktop visar historiken, men för en fullständig bisect använder du en terminal i samma repository. Om gamla commits inte går att bygga kan git bisect skip användas, men då måste osäkerheten beskrivas.

Revert eller reset?

Revert skapar en ny commit som försöker upphäva en tidigare ändring. För redan publicerade ändringar är det normalt säkrare. Reset flyttar en grenreferens; --hard kan dessutom kasta bort spårade lokala ändringar. Undvik reset och force-push på gemensamma grenar. Att återställa en merge-commit kräver extra förståelse för vilken förälder som ska behållas.

Ett säkert avslut är ofta en revert på en egen gren, tester, granskningsförfrågan, sammanslagning till skyddad main och dokumenterad driftsättning. En ändrad gren rullar inte automatiskt tillbaka ett körande system.

Fortsätt med från ärende till release och Git bisect-referensen.

Grennamn: main används som exempel. Använd master eller projektets verkliga standardgren där det behövs. Se Git-begrepp.