Git revert: ångra en AI-ändring som redan är pushad

1. Välj vad du behöver ångra

Utgå från ett konkret fel: AI-koden tog bort en kontroll i ett formulär, och ändringen är redan delad. Skriv upp commit-id, berörda filer och ett sätt att återskapa felet. Har du ännu inte hittat ändringen kan du börja med Git bisect för att hitta AI-felet. Här tar du vid när den felaktiga commiten är identifierad.

Enligt Git revert, version 2.54.0, skapar revert nya commits som vänder tidigare ändringar. Börja med rent arbetsläge. Lägg undan pågående arbete med hjälp av guiden om Git stash innan du fortsätter. En återställning av kod ersätter inte en separat åtgärd för redan ändrade produktionsdata.

Kör först träningsflödet nedan i PowerShell, block för block i samma terminal. Det använder ett nytt lokalt repository i temporärmappen. Ingen push eller kontakt med en server ingår. Proven är avsedda för dig som läsare; de redovisas inte som körda av redaktionen. Stoppa vid fel och undersök orsaken innan du fortsätter.

2. Prova en enskild commit

Exemplet använder pris.txt som en liten, synlig modell av ett fel. Basen är 100 och AI-försöket ändrar den till 0. Du sparar båda identifierarna så att du kan jämföra innehållet efter återställningen. Lokal namn- och e-postkonfiguration gäller träningsrepot. Välj ingen befintlig projektkatalog som ersättning för temporärmappen.

$provKatalog = Join-Path ([System.IO.Path]::GetTempPath()) ('revert-prov-' + [guid]::NewGuid())
New-Item -ItemType Directory -Path $provKatalog | Out-Null
Set-Location $provKatalog
git --version
git init -b main
git config user.name 'Revertprov'
git config user.email 'revertprov@example.invalid'
git config core.autocrlf false
$utf8 = New-Object System.Text.UTF8Encoding($false)
[System.IO.File]::WriteAllText("$provKatalog/pris.txt", "100`n", $utf8)
git add -- pris.txt
git commit -m 'Bas med pris 100'
if ($LASTEXITCODE -ne 0) { throw 'Basen kunde inte sparas' }
$bas = git rev-parse HEAD
[System.IO.File]::WriteAllText("$provKatalog/pris.txt", "0`n", $utf8)
git add -- pris.txt
git commit -m 'AI-forsok med fel pris'
if ($LASTEXITCODE -ne 0) { throw 'Forsoket kunde inte sparas' }
$fel = git rev-parse HEAD
git status --short
git show --stat $fel
git revert --no-edit $fel
if ($LASTEXITCODE -ne 0) { throw 'Revert stoppade; undersok laget' }
Get-Content pris.txt
git log -3 --oneline
git diff --exit-code $bas HEAD -- pris.txt

Ditt facit: filen innehåller 100, loggen innehåller basen, försöket och en ny återställningscommit, och sista jämförelsen ger exitkod 0. Detta är förväntat resultat från det konstruerade exemplet, inte inklistrad terminalutdata. --no-edit hoppar över meddelanderedigeraren enligt revert-manualen. I projektet bör du även beskriva vilket fel som motiverar återställningen i din pull request.

3. Samla ett intervall med -n

Anta att två separata AI-commits tillsammans ska bort. Nästa block lägger till två fristående filer och sparar deras bas. Använd just denna linjära provhistorik; välj inte ett intervall i ett verkligt projekt förrän du har läst vilka commits som ingår. Be särskilt om granskning om intervallet omfattar en merge eller andra utvecklares arbete.

$intervallBas = git rev-parse HEAD
[System.IO.File]::WriteAllText("$provKatalog/ai-a.txt", "forsok A`n", $utf8)
git add -- ai-a.txt
git commit -m 'AI-forsok A'
if ($LASTEXITCODE -ne 0) { throw 'Commit A misslyckades' }
[System.IO.File]::WriteAllText("$provKatalog/ai-b.txt", "forsok B`n", $utf8)
git add -- ai-b.txt
git commit -m 'AI-forsok B'
if ($LASTEXITCODE -ne 0) { throw 'Commit B misslyckades' }
git log --oneline 'HEAD~2..HEAD'
git revert -n 'HEAD~2..HEAD'
if ($LASTEXITCODE -ne 0) { throw 'Intervallrevert stoppade' }
git diff --cached
git commit -m 'Angra de tva AI-forsoken tillsammans'
if ($LASTEXITCODE -ne 0) { throw 'Aterstallningen kunde inte sparas' }
git diff --exit-code $intervallBas HEAD

-n lägger återställningen i arbetskatalog och index utan att skapa commits, enligt revert-manualen. Git revisions beskriver tvåpunktsintervallet: vänster gräns är utesluten. I provet ska du därför se just A och B i urvalet, deras borttagning i indexdiffen och ingen skillnad mot intervallbasen efter din gemensamma commit. Om urvalet visar annat ska du stoppa innan revert.

4. Välj rätt förälder vid en merge

Vid en merge använder -m ett föräldranummer från 1 för den huvudlinje som återställningen ska jämföras mot. Det betyder inte grennamn. Kontrollera föräldrarna med Git logs format %P. Nästa prov skapar själv en merge på main, där första föräldern ska vara den sparade huvudlinjen. Utgå inte från att samma siffra passar varje annan merge.

$huvudlinje = git rev-parse HEAD
git switch -c ai/merge-prov
if ($LASTEXITCODE -ne 0) { throw 'Grenbytet misslyckades' }
[System.IO.File]::WriteAllText("$provKatalog/merge-ai.txt", "AI-gren`n", $utf8)
git add -- merge-ai.txt
git commit -m 'AI-andring pa sidogren'
if ($LASTEXITCODE -ne 0) { throw 'Sidogrenens commit misslyckades' }
git switch main
if ($LASTEXITCODE -ne 0) { throw 'Atergangen misslyckades' }
git merge --no-ff ai/merge-prov -m 'Integrera AI-grenen'
if ($LASTEXITCODE -ne 0) { throw 'Merge misslyckades' }
$merge = git rev-parse HEAD
git log -1 --format='%H %P' $merge
git rev-parse ($merge + '^1')
if ((git rev-parse ($merge + '^1')) -ne $huvudlinje) { throw 'Kontrollera foraldern' }
git revert -m 1 --no-edit $merge
if ($LASTEXITCODE -ne 0) { throw 'Merge-revert stoppade' }
$mergeRevert = git rev-parse HEAD
git diff --exit-code $huvudlinje HEAD
Test-Path merge-ai.txt

Facit i ditt prov är ingen skillnad mot huvudlinjen och False från filkontrollen. Hela mergeändringen vänds relativt vald förälder. Vill du bara ta bort en liten del behöver du först avgränsa den uppgiften; välj inte merge-revert enbart för att en AI-commit finns någonstans i grenen. Låt en kollega jämföra patchen med det avsedda felet.

5. Förstå nästa merge och konflikter

Git-manualen varnar att senare merges endast tar med trädändringar från commits som inte är förfäder till den reverterade mergen. Att merga samma gren igen återinför därför inte automatiskt den borttagna ändringen. Prova i träningsrepot:

git merge ai/merge-prov
Test-Path merge-ai.txt
git revert --no-edit $mergeRevert
if ($LASTEXITCODE -ne 0) { throw 'Aterinforandet stoppade' }
Test-Path merge-ai.txt

Ditt facit är att filen fortfarande saknas efter första steget men återkommer när återställningscommiten själv reverteras. Använd inte sista kommandot i produktion innan felet är löst: i exemplet återinför du just samma AI-innehåll. Planera granskning och korrigering tillsammans, och skriv vilken ändring som ska tillbaka. Revert av revert är ett beslut om innehåll, inte ett bevis på att buggen är borta.

Om en verklig revert stannar med konflikt: läs statusen, lös berörda filer, lägg till de lösta filerna och använd git revert --continue. Vill du avbryta den pågående sekvensen använder du git revert --abort, som återgår till läget före sekvensen enligt manualen. Fortsätt inte med fler återställningskommandon i ett olöst läge. Provet ovan konstruerar ingen konflikt.

6. Ångra en pull request på GitHub

I GitHub Docs för GitHub.com beskrivs Revert som en ny pull request som vänder den ursprungliga mergecommiten. Du behöver skrivbehörighet. Öppna Pull requests, välj den mergade pull requesten och klicka Revert nära sidans slut. Granska den nya pull requestens diff och provresultat och merga den enligt projektets rutin.

GitHub anger att konflikter eller en ursprunglig merge utanför GitHub kan kräva att enskilda commits reverteras. Saknas knappen anger dokumentationen att du behöver be administratören om skrivbehörighet. Kontrollera alltså både behörighet och mergehistorik; behandla inte alla typer av integration som samma fall. I din beskrivning bör originalets pull request, felsymtom och önskat återställt beteende gå att följa.

7. Godkänn först när beteendet är tillbaka

Använd Git diff för att granska skillnaden mellan den noterade basen och återställningen. I träningsrepot kan hela trädet matcha. I ett verkligt projekt kan senare, korrekta ändringar finnas kvar: kräv då rätt beteende och granska berörda filer i stället för att kräva identitet med ett gammalt helt projekt.

Återskapa formulärfelet från första steget och skriv ditt facit innan du provar: exempelvis ska ett tomt obligatoriskt fält stoppas medan giltig inmatning fortfarande fungerar. Kör relevanta tester och kontrollera även ett närliggande fungerande fall. Skicka återställningen via projektets vanliga granskningsflöde när resultaten stämmer. Anteckna vad du har provat, vad du har sett och vilka delar du ännu inte har kontrollerat.