Git restore: ångra AI-ändringar före commit

1. Välj vad som ska ändras innan du kör

AI-assistenten har skrivit över en godkänd rubrik och lämnat din egen sidfot i samma fil. Börja med frågan: vill du ta bort innehållet ur nästa commit, eller skriva över raderna i arbetsfilen? I det första fallet avstagar du. I det andra behöver du välja exakt vilken fil eller patch som får ersättas. Läs hela diffen innan du godkänner ett destruktivt kommando.

Enligt Git restores dokumentation styr --staged och --worktree målet. Standardkällan är HEAD med --staged, annars index. HEAD är här den senaste committen. Tabellen visar förutsättningarna i övningen; vi använder en spårad textfil i ett repo utan konflikter.

Spara egna ändringar utanför repot innan du provar återställning. I övningen kopierar du filen till föräldramappen och jämför dess hash. I ett riktigt projekt behöver du dessutom bevara andra berörda filer och kontrollera att kopiorna går att läsa. Guiden lovar ingen återhämtning av ocommittat eller ospårat innehåll som redan skrivits över eller raderats.

2. Skapa ett nytt, isolerat övningsrepo

Öppna Windows PowerShell 5.1 i en separat övningsmapp. Där får varken git-restore-lab eller config.before-restore.txt finnas sedan tidigare. Kör blocken i ordning i samma fönster och avbryt vid ett oväntat resultat. Använd inte ditt pågående projekt. Identiteten och radslutsinställningen nedan gäller övningsrepot.

git --version
New-Item -ItemType Directory git-restore-lab
Set-Location git-restore-lab
git init
git config user.name "Guide Lab"
git config user.email "guide@example.invalid"
git config core.autocrlf false
@('title=Old','line2=keep','line3=keep','line4=keep','line5=keep','line6=keep','line7=keep','line8=keep','footer=Old') | Set-Content config.txt -Encoding ascii
'notes=Old' | Set-Content notes.txt -Encoding ascii
git add -- config.txt notes.txt
git commit -m "Baseline"
git status --short

Facit är en första commit med två filer och tom status. config.txt har nio rader. Mellan rubrik och sidfot ligger sju oförändrade rader, så att patchprovet kan visa dem separat. Vårt prov den 29 oktober 2026 kördes med Git 2.53.0.windows.2 och PowerShell 5.1.26100.9711. Commit-id är lokalt och behöver inte matcha vårt.

3. Bygg tre versioner och läs båda diffarna

Först lägger du en godkänd rubrik i index. Därefter efterliknar du en ny AI-redigering och en egen ändring av sidfoten. notes.txt fungerar som kontrollfil: dess ändring ska finnas kvar under hela övningen. new.txt är avsiktligt ospårad och ligger utanför återställningens filval.

(Get-Content config.txt) -replace 'title=Old','title=Approved' | Set-Content config.txt -Encoding ascii
git add -- config.txt
(Get-Content config.txt) -replace 'title=Approved','title=AI' -replace 'footer=Old','footer=Own' | Set-Content config.txt -Encoding ascii
'notes=Own' | Set-Content notes.txt -Encoding ascii
'untracked=Own' | Set-Content new.txt -Encoding ascii
Copy-Item config.txt ../config.before-restore.txt
$savedHash = (Get-FileHash config.txt).Hash
git show HEAD:config.txt
git show :config.txt
Get-Content config.txt
git status --short
git diff -- config.txt notes.txt
git diff --cached -- config.txt

Nu är rubriken Old i HEAD, Approved i index och AI i arbetsfilen. Sidfoten är Old i HEAD och index men Own i arbetsfilen. Vårt statusresultat blev MM config.txt, ett inledande blanksteg följt av M för notes.txt och ?? new.txt. Git status beskriver den första kolumnen som indexets status och den andra som arbetskatalogens i ett konfliktfritt fall.

Git diff-dokumentationen skiljer mellan arbetsfil mot index och index mot HEAD. Facit för vanlig diff är Approved till AI samt Old till Own i config.txt, och Old till Own i notes.txt. --cached visar bara rubriken Old till Approved. Läs plus- och minusraderna; en oförändrad kontextrad kan innehålla ett värde utan att det är en ändring.

4. Bevisa att återställningskällan är index

Kopian utanför repot finns nu. Följande filbegränsade kommando är destruktivt för config.txt: båda arbetsändringarna ersätts. Målet med just detta delprov är att se skillnaden mellan den godkända versionen i index och den äldre committen. notes.txt omfattas inte av filvalet.

git restore --worktree -- config.txt
git diff -- config.txt
git diff --cached -- config.txt
Get-Content config.txt

I vårt prov blev första diffen tom, medan --cached fortfarande visade Old till Approved. Arbetsfilen innehöll title=Approved och footer=Old. Återställningen gick alltså till indexets version, inte direkt till Old i HEAD. Den egna sidfoten försvann ur arbetsfilen i detta delprov; därför gjordes kopian först. Om du bara ville avstaga var detta fel kommando.

5. Avstaga och kontrollera att arbetsfilen är kvar

Återför övningskopian så att samma AI-rubrik och egna sidfot finns igen. Den här kopieringen är en del av det isolerade provet. Gör inte motsvarande överskrivning i ett aktivt projekt där nya ändringar kan ha tillkommit efter säkerhetskopian.

Copy-Item ../config.before-restore.txt config.txt
git restore --staged -- config.txt
if ((Get-FileHash config.txt).Hash -ne $savedHash) { throw 'Arbetsfilen ändrades' }
git diff -- config.txt
git diff --cached -- config.txt

Facit är att hashkontrollen inte kastar något fel. Vårt prov bekräftade oförändrade bytes. --cached blev tom: index motsvarade HEAD. Vanlig diff visade nu Old till AI och Old till Own. Den godkända mellanversionen Approved ligger inte längre i index. Avstagning sparar alltså inte ett separat godkännande åt dig; granska och välj på nytt om något ska ingå i nästa commit.

För att välja vad som ska tas med finns guiden om git add -p. Här fortsätter vi i motsatt riktning och väljer vad arbetsfilen ska förlora. Läs därför patchpromptens verb, även om y och n känns bekanta från staging.

6. Kasta AI-rubriken men behåll din sidfot

git restore --patch --worktree -- config.txt
# Svara y på blocket som ändrar title.
# Svara n på blocket som ändrar footer.
git diff -- config.txt
git diff --cached -- config.txt
Get-Content config.txt

I vårt prov visade Git två block med frågan Discard this hunk from worktree. Vi svarade y på title och n på footer. Facit blev title=Old och footer=Own. Vanlig diff innehöll bara sidfotsändringen; --cached var tom. Här betyder y att den visade ändringen kastas. Läs varje block innan du svarar, i stället för att klistra in svaren blint.

Vi fick också en whitespace-varning i patchläget med PowerShell-filens CRLF-radslut. Exitkoden var 0 och innehållskontrollen gav rätt rubrik och sidfot. En varning är ändå skäl att kontrollera filen och diffen. Om ditt patchurval inte ger samma två tydliga block: avbryt med q och granska, i stället för att acceptera ett större block som också innehåller eget arbete.

Prova slutligen helfilsvarianten i övningen. Den kastar den kvarvarande sidfoten i just config.txt. Kopian utanför repot ska fortfarande innehålla den ursprungliga arbetsversionen.

git restore --worktree -- config.txt
git diff -- config.txt
git diff --cached -- config.txt
git status --short
Get-Content notes.txt
Get-Content new.txt
if ((Get-FileHash ../config.before-restore.txt).Hash -ne $savedHash) { throw 'Kopian ändrades' }

Vårt slutresultat var två tomma diffar för config.txt, vars rubrik och sidfot båda var Old. Status visade fortsatt ändrad notes.txt och ospårad new.txt. Innehållen var notes=Own respektive untracked=Own, och kopians hash matchade. Samtliga Git-kommandon i provet gav exitkod 0. Tom diff och rätt filinnehåll är facit; en lyckad exitkod ensam räcker inte för att avgöra om rätt ändring kastades.

7. Använd rätt flöde i ditt projekt

Begränsa återställningen till en namngiven fil och kontrollera både git diff och git diff --cached före och efter. Övningen använder inga breda filval. Om en AI-assistent föreslår att ändra både index och arbetskatalog i samma anrop behöver du först bestämma om båda verkligen ska ersättas. Prova inte det som ett sätt att enbart avstaga.

Ska arbetet vänta finns ett separat flöde för att lägga undan AI-försök. Är ändringen redan committad och behöver hanteras i delad historik går du vidare till guiden om git revert. Den här övningen avslutas före en ny commit och behandlar varken publicerad historik eller återhämtning av raderade ospårade filer.