GuideGit

Gitignore i AI-projekt: ignorera rätt filer

Prova gitignore i ett separat AI-projekt. Skilj ospårat från spårat, hitta ignoreregeln och ta bort en ofarlig fil ur indexet med arbetsfilen kvar.

Publicerad

Utdragna mörka metallfack med silvergrå fronter och grönt ljus mellan skenorna.
Skilj det lokala arbetsmaterialet från filerna som ska följa med projektet.
Kort sagt

En .gitignore filtrerar avsiktligt ospårade filer. Den slutar inte spåra filer som redan finns i Git-indexet. Kontrollera därför både ignoreregeln och indexet innan du godkänner en ändring. Övningen visar skillnaden med en ofarlig textfil.

1. Bestäm vilka filer som hör till projektet

En AI-agent har skapat källkod, byggutdata och lokala inställningar. Du vill kunna granska koden utan att blanda in allt som råkar ligga på disken. Börja med en uttrycklig filpolicy för just projektet. I övningen ska src/app.js, package-lock.json och .env.example kunna versionshanteras. dist/app.js är påhittad byggutdata, node_modules/demo.txt är en påhittad beroendefil och .env.local innehåller en lokal testinställning. Dessa tre ska ignoreras.

Det är ett avgränsat beslut för övningen. I ett verkligt projekt behöver du kontrollera hur bygget, installationen och leveransen fungerar innan du döljer en katalog. En katalog som heter dist kan exempelvis vara avsiktligt versionshanterad i ditt arbetsflöde. Läs guiden om npm ci för låsfilens roll; lägg inte till package-lock.json i ignoreringen bara för att AI också skapade node_modules.

Du behöver Git och PowerShell. Kör samtliga steg i samma PowerShell-fönster. Koden skapar ett nytt repo med ett slumpat katalognamn. Alla filinnehåll är syntetiska, även miljöfilerna. Ingen riktig nyckel behövs. Om du bara vill lägga undan pågående ändringar tillfälligt är Git stash-guiden en annan uppgift.

2. Skapa ett separat övningsrepo

Det första blocket skapar en startcommit med local-settings.txt. Den filen ska avsiktligt vara spårad innan ignorereglerna tillkommer. Namn och e-post sätts endast i övningsrepot. En tom lokal exkluderingsfil används för att minska påverkan från egna globala ignoreregler. Kontrollera att den utskrivna sökvägen är övningskatalogen innan du fortsätter.

$provKatalog = Join-Path ([IO.Path]::GetTempPath()) ('gitignore-prov-' + [guid]::NewGuid().ToString('N'))
New-Item -ItemType Directory -Path $provKatalog | Out-Null
Set-Location -LiteralPath $provKatalog
Get-Location
git --version
git init --quiet
if ($LASTEXITCODE -ne 0) { throw 'Init misslyckades' }
git config user.name 'Gitignore Test'
git config user.email 'gitignore@example.invalid'
git config core.autocrlf false
git config core.excludesFile "$provKatalog/.git/empty-ignore"
git config core.hooksPath "$provKatalog/.git/empty-hooks"
$utf8 = New-Object System.Text.UTF8Encoding($false)
[IO.File]::WriteAllText("$provKatalog/.git/empty-ignore", '', $utf8)
[IO.File]::WriteAllText("$provKatalog/local-settings.txt", "theme=dark`n", $utf8)
git add -- local-settings.txt
git commit --quiet -m 'Spåra ofarlig lokal inställning'
if ($LASTEXITCODE -ne 0) { throw 'Startcommit misslyckades' }

Skapa sedan projektets övriga testfiler och fyra regler i roten. package-lock.json är här bara en tom JSON-platshållare för filklassificeringen, ingen användbar npm-låsfil. Du ska inte installera eller bygga något i övningen.

New-Item -ItemType Directory -Path src, dist, node_modules | Out-Null
[IO.File]::WriteAllText("$provKatalog/src/app.js", "console.log('test');`n", $utf8)
[IO.File]::WriteAllText("$provKatalog/dist/app.js", "generated test`n", $utf8)
[IO.File]::WriteAllText("$provKatalog/node_modules/demo.txt", "dependency test`n", $utf8)
[IO.File]::WriteAllText("$provKatalog/.env.local", "DEMO_MODE=local`n", $utf8)
[IO.File]::WriteAllText("$provKatalog/.env.example", "DEMO_MODE=example`n", $utf8)
[IO.File]::WriteAllText("$provKatalog/package-lock.json", "{}`n", $utf8)
[IO.File]::WriteAllText("$provKatalog/.gitignore", "/dist/`n/node_modules/`n/.env.local`n/local-settings.txt`n", $utf8)
Get-Content -LiteralPath ./.gitignore

Snedstrecket först förankrar reglerna vid den här .gitignore-filens katalog. Snedstrecket sist i /dist/ och /node_modules/ avser kataloger. Läs Git-dokumentationens mönsterregler om ditt projekt har en annan struktur. Här väljer du precisa rotsökvägar framför ett brett mönster som *.json, vilket skulle dölja testets låsfil.

3. Kontrollera status och den matchande regeln

git status --short --untracked-files=all --ignored
git check-ignore -v -- dist/app.js node_modules/demo.txt .env.local
git ls-files -- local-settings.txt
git check-ignore -v -- local-settings.txt
$LASTEXITCODE
git check-ignore -v --no-index -- local-settings.txt

Det första kommandots facit är fyra ospårade filer markerade med ?? och tre ignorerade filer markerade med !!. local-settings.txt saknas i statusen eftersom den spårade filen är oförändrad. Enligt Git status visar flaggorna även ignorerade filer och enskilda filer i katalogerna. Jämför hela listan, inte bara frånvaron av dist.

?? .env.example
?? .gitignore
?? package-lock.json
?? src/app.js
!! .env.local
!! dist/app.js
!! node_modules/demo.txt

De tre första regelträffarna ska ange .gitignore, rad 1, 2 respektive 3, det matchande mönstret och sökvägen. Exempelvis får dist/app.js raden nedan. Detaljerna gör skillnad när en fil ignoreras av en annan källa än den du just redigerade.

.gitignore:1:/dist/    dist/app.js

För local-settings.txt ska ls-files skriva ut filnamnet. Git ls-files visar här att filen finns i indexet. Vanlig check-ignore ger däremot inget svar och exitkod 1 i provet. Det betyder inte att du glömde regel 4: check-ignore hoppar normalt över spårade filer. Med --no-index analyseras regeln utan den begränsningen, och facit blir .gitignore:4:/local-settings.txt följt av filnamnet.

--no-index ändrar inte spårningen; det är en analysflagga. Om ditt facit avviker, läs källfilen och radnumret som faktiskt rapporteras. Kontrollera också arbetskatalogen. Lägg inte till allt med tvång för att komma runt en regel du ännu inte förstår.

4. Sluta spåra just den ofarliga filen

Nu ska local-settings.txt lämna indexet men finnas kvar på disken. Förhandsvisa den riktade åtgärden och utför den sedan. Git rm-dokumentationen anger att --cached lämnar arbetsfilerna kvar och att -n visar åtgärden utan att utföra den. Använd filnamnet uttryckligen.

git rm -n --cached -- local-settings.txt
git rm --cached -- local-settings.txt
if ($LASTEXITCODE -ne 0) { throw 'Riktad indexändring misslyckades' }
Test-Path -LiteralPath ./local-settings.txt
Get-Content -LiteralPath ./local-settings.txt
git ls-files -- local-settings.txt
git diff --cached --name-status
git diff --cached -- local-settings.txt
git status --short --untracked-files=all --ignored

Facit: Test-Path ger True och innehållet är fortfarande theme=dark. ls-files ger nu ingen rad för filen. Den cachade diffen visar D för local-settings.txt och borttagningen av dess rad. Statusen visar både D i första kolumnen och !! för samma sökväg: borttagningen är staged jämfört med startcommitten, medan den kvarvarande arbetsfilen omfattas av ignoreregeln.

Granska den staged ändringen även om filen finns kvar i Utforskaren. Diskinnehåll och nästa commit är olika kontrollpunkter. Om kommandot vägrar i ett annat projekt ska du läsa felmeddelandet och jämföra index och arbetsfil innan du gör något mer. Övningen kräver ingen force-flagga och ingen omindexering av hela projektet.

5. Granska vad nästa commit skulle innehålla

Lägg till de fyra avsedda projektfilerna uttryckligen och läs hela diffen. Då går det att se om ett AI-förslag råkade dölja källkod eller lägga till lokalt arbetsmaterial. Provets slutindex ska innehålla .env.example, .gitignore, package-lock.json och src/app.js.

git add -- .gitignore src/app.js .env.example package-lock.json
git diff --cached --name-status
git diff --cached
git ls-files
git show HEAD:local-settings.txt

Facit för namnstatus är fyra A och ett D: local-settings.txt tas bort i den föreslagna committen. Det sista kommandot visar fortfarande theme=dark från startcommitten. Ignoreringen har alltså inte skrivit om den tidigare committen. Du behöver inte skapa någon ytterligare commit för att genomföra övningen; låt katalogen ligga kvar medan du jämför faciten.

Om en riktig hemlighet redan har delats räcker inte en ny ignoreregel eller den här indexändringen. Följ i stället artikeln om läckta hemligheter i kodbasen. Den här guiden slutar vid filpolicy, regelanalys och granskad lokal indexändring.

Källor och genomfört prov

Primärkällor kontrollerade 24 oktober 2026. Kommandoflödet kördes i ett separat syntetiskt repo med Git 2.53.0.windows.2 och PowerShell. Statusrader, regelnummer, exitkod 1 för vanlig check-ignore på spårad fil, staged borttagning och kvarvarande arbetsfil stämde med faciten. Ingen installation, AI-generering eller körning på ett befintligt projekt ingick.