Een .gitignore-bestand is een tekstbestand dat in uw git-repository wordt geplaatst git om bepaalde bestanden en mappen die u niet wilt uploaden naar uw hoofdrepository niet te volgen. Het heeft veel toepassingen en je zult het bijna altijd moeten configureren als je een nieuwe opslagplaats instelt.
Wat’ ;s Het punt van .gitignore?
In de meeste projecten is er een verschil tussen code/config en gegenereerde bestanden van die code of config. Dit laatste is meestal niet handig en kan over het algemeen worden genegeerd.
Meestal wil je alleen dat de code en configuratie worden gevolgd via git. Dit komt omdat de gegenereerde bestanden kortstondig zijn en als u ze verwijdert, kunt u ze gewoon opnieuw genereren. Het heeft vaak geen zin om ze te uploaden, omdat ze de zaken alleen maar ingewikkelder maken en onnodige samenvoegconflicten veroorzaken.
Dit is een brede definitie, dus laten we eens naar een voorbeeld kijken. In Node JS-projecten is er een map met de naam node_modules die alle externe pakketten bevat die uw code moet uitvoeren. U kunt deze map verwijderen en volledig opnieuw opbouwen door npm install uit te voeren, waarbij de package.json-configuratie wordt gebruikt om naar pakketten te zoeken.
Dus wat heeft het voor zin om de map node_modules in Git te hebben? Er is er niet echt een, omdat het ingewikkelder is, problemen kan veroorzaken en in veel gevallen zelfs de grootte van de Git-repo drastisch kan vergroten.
Advertentie
Als je negeer de hele directory, al uw collega's kunnen nog steeds hun eigen lokale kopie genereren vanuit het package.json-bestand. Dus in plaats daarvan moet alleen package.json worden bijgehouden in Git. De meeste dingen die aan .gitignore worden toegevoegd, volgen dit patroon. Bouw artefacten, zoals een ./bin/-map, zet je niet vast omdat ze een direct resultaat zijn van de code zelf.
Er kunnen voor het gemak ook andere dingen aan .gitignore worden toegevoegd. MacOS genereert systeembestanden genaamd .DS_store, die u altijd kunt negeren. Misschien sla je API-sleutels op in .env/waarvan je niet wilt dat ze worden gevolgd in bronbeheer, je kunt die ook toevoegen. Caches, logs en andere uitvoer kunnen meestal worden genegeerd.
Gebruik van .gitignore
U moet een bestand maken met de naam .gitignore, zonder extensies, in de hoofdmap van uw project waar uw .git-map zich bevindt. U kunt dit doen vanuit uw bestandsbrowser of vanaf de opdrachtregel met een CLI-teksteditor:
nano .gitignore
Je kunt dit op veel manieren configureren, maar de belangrijkste tools die je hebt zijn:
- * jokertekens, die overeenkomen met elke tekst en kunnen worden gebruikt om overeenkomen met elke map of elk bestand, ongeacht de extensie.
- !, wat werkt als een soort witte lijst die een eerder uitgesloten bestand negeert. Het belangrijkste nadeel hiervan is dat het bestand alleen op de witte lijst wordt gezet als het direct is uitgesloten, en niet werkt voor bestanden in mappen die volledig zijn uitgesloten.
- **, wat alles recursief in mappen plaatst. **/*.json komt bijvoorbeeld overeen met elk JSON-bestand, ongeacht waar het zich bevindt, en src/** komt recursief overeen met elk bestand in de map. Dit is handig als u de hele map op de witte lijst wilt zetten en niet de hele map wilt negeren.
Een Node JS-gitignore kan er bijvoorbeeld als volgt uitzien:
node_modules/build/npm-debug.log .env .env.test .env.production .DS_Store .npm .eslintcache logs/*.log npm-debug.log*
Bestanden op de witte lijst zetten met ! kan voor veel configuraties erg handig zijn. In een van mijn projecten had ik bijvoorbeeld een tool genaamd steamcmd die afhankelijkheden voor gameservers van Steam downloadt. Deze tool is verpakt in een enkel draagbaar uitvoerbaar bestand, maar het produceert een heleboel rommel die ik niet wil volgen in Git.
Advertentie
De oplossing was om alles in de map te negeren, maar het uitvoerbare bestand op de witte lijst te zetten. Dit werkt voor elk draagbaar uitvoerbaar bestand dat zich op deze manier uitbreidt of anderszins onnodige rommel in de map produceert.
Project/steamcmd/** !Project/steamcmd/steamcmd.exe
gitignore gebruikt ook enkele andere Unix-globbing-patronen voor overeenkomende tekenreeksen, zoals een vraagteken voor het matchen van een enkel teken, of [az] die overeenkomen met tekensets.
Je kunt ook meerdere .gitignore-bestanden schrijven die bestanden relatief aan zichzelf kunnen matchen. Dit is niet echt handig omdat je de regels gewoon in het rootbestand kunt opnemen, wat gemakkelijker te volgen is, maar het kan in sommige gevallen helpen bij het herhalen van de code. De oplossing is echter om tekensets te gebruiken om meerdere mappen te matchen. Bijvoorbeeld, hoofdletters en kleine letters matchen met een set:
# Build results [Dd]ebug/[Dd]ebugPublic/[Rr]elease/[Rr]eleases/
Als je problemen hebt met uw .gitignore-configuratie kunt u deze debuggen met het check-ignore Git-commando:
git check-ignore -v testfile.json
Global .gitignore
Git heeft ook een globale instelling voor .gitignore, maar het zou’ t echt worden gebruikt in de meeste gevallen. Dit komt omdat de algemene .gitignore op je computer niet van toepassing is op je collega's, en alleen op commits die zijn gemaakt met je exemplaar van Git.
Als je het toch wilt instellen, kun je dat doen dus met het volgende commando:
git config –global core.excludesfile ~/.globalignore
Forceer het plegen of opbergen van genegeerde bestanden
Geforceerd plegen is over het algemeen een slecht idee — je zou waarschijnlijk een witte lijst voor dit specifieke bestand moeten toevoegen, want eenmaal vastgelegd, zullen updates voor dit bestand niet worden bijgehouden. Maar als je iets handmatig wilt vastleggen, kun je git add met de –force parameter uitvoeren:
git add -f debug.log Advertisement
Evenzo kan git stash ook lokale wijzigingen opslaan in genegeerde bestanden, wat eigenlijk handig kan zijn omdat het geen effect heeft op de externe repo:
git stash –all