Git add -p: välj delar av AI-ändringen till commit

1. Bestäm vad committen ska innehålla

Din avgränsning är konkret: title ska bytas från Old till New, medan footer ska vara Old i committen. Arbetsfilen kommer ändå att innehålla båda ändringarna. Skriv den meningen innan du börjar. Då har du ett facit som går att jämföra med patchen, även om assistentens förklaring låter övertygande.

Enligt Git add-dokumentationen förbereder index innehållet för nästa commit. Med -p väljer du patchdelar mellan arbetskatalog och index. Att acceptera en del betyder inte att resten av arbetsfilen försvinner. Urvalet bestämmer vad du förbereder för commit.

Artikeln om varför små diffar vinner behandlar arbetsmetoden. Här behöver du kunna svara på en smalare fråga: exakt vilka rader lämnar du vidare? Om två beteenden är beroende av varandra måste den valda delen fortfarande fungera utan den bortvalda.

2. Bygg ett separat övningsrepo

Öppna PowerShell i en egen övningsmapp där katalogerna git-add-p-lab och git-add-p-verify inte redan finns. Kör inte blocket inne i ditt projekt. Git ska vara installerat. Identiteten nedan är en lokal providentitet; använd din vanliga identitet i verkligt arbete. Konfigurationen skrivs för övningsrepot.

git --version
New-Item -ItemType Directory git-add-p-lab
Set-Location git-add-p-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','footer=Old','line6=keep','line7=keep','line8=keep') | Set-Content config.txt -Encoding ascii
git add -- config.txt
git commit -m "Baseline"
git status --short

Facit är en första commit med åtta textrader och tom status. Filen är nu spårad, vilket är grundprovets förutsättning. De tre oförändrade raderna mellan title och footer är avsiktliga: de gör det möjligt att demonstrera delning utan att ta till manuell patchredigering.

Vårt eget prov genomfördes den 28 oktober 2026 med Git 2.53.0.windows.2 på Windows. Vi provade både en fil skriven med LF och PowerShell-varianten ovan. Båda gav samma innehållsfacit. Dina commit-id blir egna och ska inte jämföras bokstavligen med våra.

3. Gör två ändringar och välj med s, y och n

Efterlikna assistentens blandade leverans genom att ändra de två värdena. Filnamnet och radernas ordning är oförändrade. Ändringarna står nära varandra så att vårt prov först visade en gemensam hunk, alltså ett diffblock. Läs din faktiska prompt innan du svarar.

(Get-Content config.txt) -replace 'title=Old','title=New' -replace 'footer=Old','footer=New' | Set-Content config.txt -Encoding ascii
git diff -- config.txt
git add -p -- config.txt

I patchläget betyder y att delen tas med, n att delen lämnas utanför och s att Git försöker dela blocket. Valen beskrivs i Git adds interaktiva läge. I vårt prov svarade vi s på det gemensamma blocket, y på title och n på footer. Git delade blocket i två delar.

Svara ett val i taget. Klistra inte in s, y och n blint: om din konfiguration redan visar två separata block väljer du y för title och n för footer. Plusraderna visar nya värden, minusraderna gamla. Oförändrade kontextrader hjälper dig lokalisera ändringen.

4. Läs två diffar före commit

Git diff-dokumentationen skiljer på arbetsfil mot index och index mot HEAD. Därför behöver du båda vyerna. I vårt prov gav följande kommandon varsin tydligt avgränsad ändring:

git diff --cached -- config.txt
git diff -- config.txt

Facit för --cached var enbart ersättningen title=Old till title=New. Facit för vanlig diff var enbart footer=Old till footer=New. Title=New kunde synas som oförändrad kontext i den senare vyn; det är ingen andra ändring. Bedöm radprefixen, inte bara om ett ord förekommer.

Om båda ändringarna syns i --cached har du inte nått facit. Skapa ingen commit förrän urvalet är rätt. Läs även hela den förberedda diffen utan filfilter, eftersom annat kan ligga i index. Övningen började med tomt index och ändrade bara config.txt; den förutsättningen behöver du kontrollera i ditt projekt.

git diff --cached
git commit -m "Update title only"
git diff HEAD^ HEAD -- config.txt

Vårt utfall blev en commit med en tillagd och en borttagen rad: bara title. Den sista jämförelsen visade samma ändring mellan committen och dess förälder. Använd commitkommandot som det står. Varianten med -a kan ta med ytterligare spårade arbetsändringar, vilket också framgår av Git diff-dokumentationens exempel.

5. Verifiera committen i en ren arbetskatalog

Din arbetsfil innehåller fortfarande footer=New. Ett lyckat test där skulle prova en kombination som inte finns i committen. Vi väljer i stället en ren katalog från HEAD. Git worktree kan checka ut en commit med separat index; --detach gör provkatalogens HEAD frikopplad från en gren. Läs worktree-guiden för ett längre arbetsflöde.

git worktree add --detach ../git-add-p-verify HEAD
git -C ../git-add-p-verify status --short
$commitLines = Get-Content ../git-add-p-verify/config.txt
if ($commitLines[0] -ne 'title=New' -or $commitLines[4] -ne 'footer=Old') { throw 'Fel innehåll i committen' }
'PASS: title=New, footer=Old'
git status --short
git diff -- config.txt

Facit är tom status i provkatalogen, PASS från innehållskontrollen och en kvarvarande footer-ändring i originalkatalogens diff. Det var vårt faktiska resultat. Status i originalet visade en modifierad config.txt. Den rena katalogen innehöll title=New samt footer=Old.

Det här är ett innehållsprov för textfilen, inte ett funktionstest av en app. För ett riktigt projekt kör du relevanta tester i den rena katalogen, med nödvändiga beroenden och miljö på plats. Ett test som kräver den bortvalda ändringen visar att uppdelningen behöver omprövas. Ta bort den rena provkatalogen när du är färdig:

git worktree remove ../git-add-p-verify

Borttagningen lyckades i vårt prov. Footer-ändringen låg kvar i originalet. Om den ska vänta finns guiden om undanläggning med stash. Att parkera arbete och att välja innehåll till nästa commit är olika beslut.

6. När s inte räcker och filen är ny

Vi gjorde ett separat sidoprov med title och footer direkt efter varandra i en spårad fil. Båda ersattes samtidigt. Git erbjöd ingen s i prompten och svarade att blocket inte kunde delas när vi ändå försökte. S är alltså inte en väljare för varje enskild rad.

En nybörjarvänlig väg är att spara den fullständiga önskade filen utanför repot, återställa bara den oönskade redigeringen i editorn och sedan välja på nytt. Kontrollera diffen före commit och återinför den sparade andra ändringen efteråt. Skriv inte över hela filen om nya redigeringar hunnit tillkomma. Manuell patchredigering med e finns, men behövs inte för grundprovet.

En helt ny, ospårad fil är ett annat fall. Vår nya textfil gav No changes när vi körde add -p direkt mot den. Git add beskriver -N, intent-to-add, som registrering av en avsikt att lägga till filen utan innehållet. Den vägen ingår inte i grundprovet. Inspektera nya filer separat medan du lär dig urval ur en spårad fil.