Bestanden buiten Git houden

Een echt project maakt bestanden die op je computer horen, maar niet in zijn geschiedenis. Een omgevingsmap kan opnieuw worden opgebouwd, een cache wordt automatisch gemaakt en een lokaal instellingenbestand kan waarden bevatten die niet met het project mee mogen. Het klaargezette weerberichtproject heeft alle drie naast bruikbare bronbestanden staan.

Deze les gebruikt alleen nepinstellingen. API_TOKEN=demo-only-not-a-secret kan nergens toegang toe geven. Als een echt toegangsmiddel al in een commit is terechtgekomen, is het niet genoeg om het uit de nieuwste momentopname te verwijderen: het moet worden vervangen en ongeldig gemaakt, en het opschonen van oude geschiedenis is een aparte taak. Dit hoofdstuk voorkomt die fout voordat ze gebeurt.

Bekijk wat Git gaat bewaren

Je gebruikt git status al om de branch en alle nog openstaande paden te zien. Voer die opdracht uit voordat je iets verandert:

git status

Het rapport toont local.env onder Changes to be committed. Het staat al in het staginggebied: de index volgt het voor de volgende commit, hoewel nog geen commit het bevat. Het rapport toont ook bestanden onder build/, __pycache__/ en .venv/ als untracked. Dat zijn gegenereerde uitvoer, een Python-cache en een lokale omgeving. Geen van die bestanden hoort in de projectgeschiedenis.

De vastgelegde examples/local.env is anders. Het is een onschuldig voorbeeld dat iemand kan kopiëren. De regel voor het instellingenbestand in de hoofdmap mag dat dieper gelegen voorbeeld daarom niet verbergen.

Beschrijf welke bestanden er niet bij horen

Een bestand met de naam .gitignore legt projectpaden vast die Git normaal ongetrackt moet laten. Dat bestand zelf hoort in de repository, zodat iedereen die het project krijgt dezelfde bescherming heeft. Ignore-regels veranderen wat Git aanbiedt voor een toekomstige commit; ze wissen geen pad dat al in een commit staat.

Open het nieuwe bestand met de terminaleditor uit hoofdstuk 2. nano -w opent nano zonder harde regelafbrekingen in te voegen wanneer de terminal smal is:

nano -w .gitignore

Voer deze vier regels in:

/local.env
build/
__pycache__/
.venv/

De eerste regel is een verankerd patroon. De / aan het begin verankert local.env aan de hoofdmap van de repository. Zo beschermt die het lokale bestand zonder ook examples/local.env te negeren.

De andere regels zijn mappatronen. Een / aan het einde zegt dat de naam een map is en negeert de bestanden eronder. build/ beschermt builduitvoer. Omdat __pycache__/ en .venv/ geen schuine streep aan het begin hebben, wordt een map met zo’n naam overal in het project genegeerd.

Sla op met Ctrl-O, druk op Enter om .gitignore te bevestigen en sluit daarna af met Ctrl-X.

Voer git status opnieuw uit. De gegenereerde mappen vervuilen de lijst met ongetrackte bestanden niet meer, maar local.env staat nog in het staginggebied:

git status

Dat resultaat is bewust. Ignore-regels overrulen de index niet. Git heeft local.env al klaargezet, dus je moet de indexvermelding verwijderen terwijl je het werkbestand behoudt.

Verwijder de indexkopie en behoud het bestand

git rm verwijdert een pad normaal uit zowel Gits index als de werkboom. De optie --cached beperkt dat tot de index: Gits klaargezette volgende momentopname. In git rm --cached local.env benoemt het laatste argument het ene geïndexeerde pad dat je niet meer wilt volgen. Het bestand op schijf blijft bestaan.

Voer de opdracht uit en vraag daarna opnieuw de status op:

git rm --cached local.env
git status

local.env verdwijnt uit het rapport omdat het bestand nu ongetrackt is en de ignore-regel geldt. De nepinhoud staat nog op schijf.

Vraag Git of de regels overeenkomen

git check-ignore toetst paden aan de ignore-regels van de repository. Geef na de opdracht één of meer paden mee. De opdracht drukt de genegeerde paden af en niets voor een pad dat niet overeenkomt.

Controleer elke beschermde soort:

git check-ignore local.env build/preview.txt __pycache__/forecast.cpython-313.pyc .venv/bin/python

Alle vier de paden horen te worden afgedrukt. De opdracht controleert gedrag in plaats van je uit de schrijfwijze van het patroon te laten afleiden wat er gebeurt. Dat is nuttig wanneer een ignore-regel langer of minder duidelijk is dan deze.

Commit de bescherming, niet de privébestanden

git add .gitignore staget alleen het ignore-bestand. De volgende git status is je controle: die hoort .gitignore klaar voor een commit te tonen en geen van de beschermde paden. Daarna legt git commit die ene samenhangende wijziging vast. De optie -m geeft het onderwerp tussen aanhalingstekens mee zonder een editor te openen.

git add .gitignore
git status
git commit -m "Keep local project files out of Git"
git status

De laatste status hoort een schone werkboom te melden. De lokale en gegenereerde bestanden bestaan nog, maar genegeerde bestanden maken de werkboom niet vuil. Belangrijker: geen ervan is in een commit terechtgekomen.

Laat een patroon op een groep bestandsnamen passen

Een ander project wil misschien elk bestand dat eindigt op .env privé houden in plaats van alleen één bestand in de hoofdmap. In een ignore-patroon staat * voor elke reeks tekens binnen een naam. Het patroon *.env past daarom op local.env en testing.env; zonder schuine streep past het ook op zulke namen in submappen. Het past niet op environment.txt.

Behoud /local.env in deze oefening: de onschuldige examples/local.env is bewust toegestaan. Kies voor het andere project van de eindopdracht, waar elk .env-bestand privé moet blijven, de bredere regel *.env. Het patroon volgt wat het project nodig heeft.

Vergelijk voor je verdergaat settings/testing.env en settings/environment.txt. Welke zou *.env negeren? De eerste naam eindigt op .env en past dus; de tweede niet. Gebruik git check-ignore met representatieve namen wanneer je de regels van je eigen project controleert.

Je hebt van een herhaalde opruimkeuze projectgedrag gemaakt. De volgende les past de andere helft van de gewoonte toe: bekijk één samenhangende wijziging voordat je de momentopname een bruikbaar onderwerp geeft.