Niet-getrackte bestanden verwijderen in Git

In Git is het .gitignore-bestand een essentieel hulpmiddel dat je helpt beheren welke bestanden en mappen in je versiebeheerde repository worden opgenomen. Met .gitignore kunnen ontwikkelaars voorkomen dat onnodige bestanden worden gevolgd, zoals logbestanden, afhankelijkheden of systeemgebonden bestanden. Deze gids laat zien hoe je een .gitignore-bestand efficiënt maakt en gebruikt. Het .gitignore-bestand vertelt Git welke bestanden of mappen moeten worden genegeerd in een project. Het stelt ontwikkelaars in staat om bestanden die niet nodig zijn voor het project uit te sluiten, waardoor de versiegeschiedenis schoner en efficiënter blijft. Waarom .gitignore gebruiken Rommel voorkomen: voorkom dat grote of onnodige bestanden je repository vervuilen. Privacy: houd gevoelige informatie zoals API-sleutels, inloggegevens of configuratiebestanden buiten versiebeheer. Efficiëntie: stroomlijn samenwerking door ervoor te zorgen dat alleen essentiële bestanden worden gevolgd en gedeeld. Een .gitignore-bestand maken Een .gitignore-bestand maken is eenvoudig. 1. Navigeer naar je Git-repository. Open je terminal en navigeer naar de hoofdmap van je Git-project. cd /path/to/your/git/project 2. Maak het .gitignore-bestand. Je kunt het bestand maken met de volgende opdracht: touch .gitignore 3. Open en bewerk het .gitignore-bestand. Open het .gitignore-bestand in je teksteditor en voeg de bestanden of mappen toe die Git moet negeren. Bijvoorbeeld: # node_modules-map negerennode_modules/# Logbestanden negeren*.log# .env-bestanden negeren.env 4. Sla de wijzigingen op en commit ze. Nadat je het bestand hebt bewerkt, sla je het op en commit je de wijzigingen in Git. git add .gitignoregit commit -m "Add .gitignore" Veelgebruikte patronen in .gitignore Er zijn verschillende veelvoorkomende patronen die gebruikt worden in .gitignore-bestanden om bestanden of mappen uit te sluiten. Hieronder enkele veelgebruikte voorbeelden. Bestanden negeren op basis van extensie: *.log   # Alle logbestanden negeren*.tmp  # Alle tijdelijke bestanden negeren*.swp  # Swap-bestanden van teksteditors negeren Specifieke mappen negeren: /logs/   # De logs-map negeren/temp/   # De temp-map negeren Verborgen bestanden negeren: .*   # Alle verborgen bestanden negeren die met een punt beginnen (bijv. .DS_Store) Bestanden in een specifieke map negeren: /docs/*.pdf   # Alle PDF-bestanden in de docs-map negeren Een patroon negeren (bestanden opnemen die eerder uitgesloten waren): *.pdf    # Alle PDF-bestanden negeren!resume.pdf # resume.pdf niet negeren Bestanden globaal vs. lokaal negeren Hoewel .gitignore meestal in de hoofdmap van je repository wordt aangemaakt, kun je Git ook configureren om bestanden globaal te negeren, waarvoor het geldt in al je repositories. Bestanden lokaal negeren Als je bestanden alleen in de huidige repository wilt uitsluiten, bewerk je eenvoudig het .gitignore-bestand van dat project. De uitsluiting geldt dan uitsluitend voor deze repository. Bestanden globaal negeren Om een globaal .gitignore-bestand te maken dat in alle repositories geldt, volg je deze stappen: 1. Maak een globaal .gitignore-bestand: touch ~/.gitignore_global 2. Voeg patronen toe aan het globale .gitignore-bestand: Bewerk het bestand en voeg patronen toe voor bestanden die je overal wilt negeren. Bijvoorbeeld: *.log*.tmp.DS_Store 3. Configureer Git om het globale .gitignore-bestand te gebruiken: git config --global core.excludesfile ~/.gitignore_global Best practices voor het gebruik van .gitignore Volg deze best practices om het meeste uit .gitignore te halen: Voeg .gitignore vroeg toe Maak een .gitignore-bestand zodra je een project start om te voorkomen dat onnodige bestanden worden gevolgd. Houd het georganiseerd Houd je .gitignore overzichtelijk door verwante patronen te groeperen en opmerkingen toe te voegen. Bijvoorbeeld: # Door het besturingssysteem gegenereerde bestanden.DS_StoreThumbs.db# Node.js-afhankelijkhedennode_modules/ Commiteer geen gevoelige informatie Gebruik .gitignore om ervoor te zorgen dat privébestanden zoals API-sleutels en configuratie-instellingen niet per ongeluk in versiebeheer terechtkomen. Test je .gitignore Gebruik git status om te controleren of je .gitignore-bestand bestanden correct uitsluit. Als een bestand nog steeds gevolgd wordt, kan het zijn dat het al in de repository zat voordat het werd genegeerd. Problemen met .gitignore oplossen Soms worden bestanden die genegeerd zouden moeten worden toch gevolgd. Hieronder staan enkele veelvoorkomende oorzaken en oplossingen. Bestanden die al gevolgd worden Als een bestand al aan de repository was toegevoegd voordat het in .gitignore werd opgenomen, blijft Git het volgen. Om het volgen van het bestand te stoppen: 1. Verwijder het bestand uit Git zonder het lokaal te verwijderen: git rm --cached filename 2. Voeg het bestand toe aan .gitignore. 3. Commit het bijgewerkte .gitignore-bestand en de verwijdering uit de cache: git commit -m "Update .gitignore and remove cached files" Problemen met hoofdletters en kleine letters Git is hoofdlettergevoelig, dus zorg ervoor dat de patronen in je .gitignore exact overeenkomen met de bestandsnamen. Bijvoorbeeld: file.txt # Negeert file.txt maar niet File.txt Testen met git check-ignore Om te controleren of een bestand correct wordt genegeerd, kun je de opdracht git check-ignore gebruiken: git check-ignore -v filename Deze opdracht toont de regel die verantwoordelijk is voor het negeren van een bepaald bestand. Conclusie Door .gitignore effectief te gebruiken, kun je beheren welke bestanden in je Git-repository worden opgenomen en ervoor zorgen dat alleen essentiële bestanden worden gevolgd. Volg de stappen in deze gids om je .gitignore-bestand te maken, aan te passen en problemen op te lossen voor efficiënt versiebeheer.

In het versiebeheersysteem Git zijn er twee manieren om één branch met een andere te combineren, vertegenwoordigd door verschillende commando’s: git merge. Commits van de ene branch worden overgebracht naar een andere door een merge commit te maken. git rebase. Commits van de ene branch worden overgebracht naar een andere branch terwijl de oorspronkelijke volgorde van wijzigingen behouden blijft. Eenvoudig gezegd: met git merge worden de commits van een branch “samengevoegd” tot één commit, terwijl ze met git rebase ongewijzigd blijven, maar de branches toch worden gecombineerd. Het git rebase-commando maakt het dus mogelijk om de commits van beide branches te combineren en een gedeelde wijzigingsgeschiedenis te vormen. Deze gids behandelt het git rebase-commando, dat verantwoordelijk is voor het herbaseren (rebasen) van commits (wijzigingen) van de ene branch naar een andere. Alle voorbeelden in deze gids gebruiken Git versie 2.34.1, uitgevoerd op een Hostman-server met het Ubuntu 22.04-besturingssysteem. Je kunt deze handleidingen gebruiken om Git op je machine te installeren: Installing Git on Ubuntu Installing Git on Windows Wat is Git Rebase Git Rebase is een krachtig Git-commando dat voornamelijk wordt gebruikt om wijzigingen van de ene branch in een andere te integreren door de commitgeschiedenis te herschrijven. In tegenstelling tot git merge, dat een nieuwe merge commit maakt om branches te combineren en de geschiedenis van beide behoudt, werkt git rebase door een reeks commits van de ene branch naar een andere te verplaatsen of te “herhalen”. Dit proces resulteert in een lineaire geschiedenis, waardoor het lijkt alsof de feature branch rechtstreeks is ontwikkeld vanaf de meest recente commit van de doelbranch, zoals main of master. Op deze manier wordt de commitgeschiedenis opgeschoond en worden onnodige merge commits verwijderd, wat leidt tot een overzichtelijkere projectgeschiedenis. Hoe Git Rebase werkt De beste manier om te begrijpen hoe rebasing in Git werkt, is door naar een abstracte repository met meerdere branches te kijken en de rebase-operatie stap voor stap te analyseren. Branches aanmaken Laten we aannemen dat we een repository hebben gemaakt met één enkele branch, master, die slechts één commit bevat. De master-branch ziet er als volgt uit: master   commit_1 Vervolgens hebben we op basis van master een nieuwe branch aangemaakt, hypothesis, waarin we enkele functies wilden testen. In deze nieuwe branch hebben we meerdere commits gemaakt om de code te verbeteren. De branch ziet er nu als volgt uit: hypothesis   commit_4   commit_3   commit_2   commit_1 Later hebben we nog een commit toegevoegd aan de master-branch om een kwetsbaarheid dringend te verhelpen. De master-branch ziet er nu als volgt uit: master   commit_5   commit_1 Onze repository bevat nu twee branches: master   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_1 De master-branch is de hoofdbranch, terwijl hypothesis een secundaire (afgeleide) branch is. Latere commits worden boven eerdere vermeld, vergelijkbaar met de uitvoer van het commando git log. Branches samenvoegen Stel dat we willen doorgaan met werken aan de functie die we eerder naar de aparte branch hypothesis hebben verplaatst. Deze branch bevat echter niet de kritieke bugfix die we in master hebben aangebracht. Daarom willen we de toestand van hypothesis synchroniseren met master zodat de fix-commit ook in de feature branch verschijnt. Met andere woorden, we willen dat de repositorystructuur er als volgt uitziet: master   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_5   commit_1 Zoals je kunt zien, herhaalt de branch hypothesis nu exact de geschiedenis van master, ook al is hij oorspronkelijk vóór commit_5 aangemaakt. Met andere woorden: hypothesis bevat nu de geschiedenis van beide branches — die van zichzelf en die van master. Om dit te bereiken, moeten we een rebase uitvoeren met het commando git rebase. Daarna kunnen de wijzigingen in hypothesis worden samengevoegd met master via het klassieke git merge-commando, dat een merge commit maakt. De repositorystructuur ziet er daarna als volgt uit: master   commit_merge   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_5   commit_1 Bovendien kan het uitvoeren van git merge na git rebase de kans op conflicten verkleinen. Praktijk: git rebase Nu we het theoretische aspect van het git rebase-commando hebben behandeld, kunnen we overgaan tot het testen ervan in een echte repository van een voorbeeldproject. De repositorystructuur zal dezelfde zijn als in het eerdere theoretische voorbeeld. Een repository aanmaken Laten we eerst een aparte map maken om de repository in te plaatsen: mkdir rebase Ga er vervolgens in: cd rebase We kunnen nu de repository initialiseren: git init In de console verschijnt een standaard informatief bericht: hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: ... In de huidige map verschijnt een verborgen map genaamd .git, die je kunt bekijken met het volgende commando: ls -a De vlag -a betekent all en maakt het mogelijk om het bestandssysteem in uitgebreide modus te bekijken. De inhoud zal zijn: .  ..  .git Voordat we commits maken, moeten we enkele basisgebruikersgegevens instellen. Eerst de naam: git config --global user.name "NAME" Daarna het e-mailadres: git config --global user.email "NAME@HOST.COM" De master-branch vullen Met behulp van eenvoudige tekstbestanden zullen we het toevoegen van verschillende functies aan het project simuleren. Elke nieuwe functie wordt weergegeven als een afzonderlijke commit. Maak een bestand voor de eerste geïmproviseerde functie: nano function_1 Voeg de volgende inhoud toe: Function 1 Indexeer vervolgens de aangebrachte wijzigingen in de repository: git add . Controleer voor de zekerheid de indexstatus: git status In de console verschijnt het volgende bericht, waarin de geïndexeerde wijzigingen worden weergegeven: On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: function_1 We kunnen nu committen: git commit -m "commit_1" De console toont een bericht dat de succesvolle commit in master bevestigt: [master (root-commit) 4eb7cc3] commit_1  1 file changed, 1 insertion(+)  create mode 100644 function_1 De hypothesis-branch vullen Laten we nu een nieuwe branch maken met de naam hypothesis: git checkout -b hypothesis De vlag -b zorgt ervoor dat we direct overschakelen naar de nieuwe branch. De console geeft een bevestigingsbericht weer: Switched to a new branch 'hypothesis' Vervolgens maken we drie opeenvolgende commits met drie bestanden, vergelijkbaar met master: commit_2 met bestand function_2 en inhoud: Function 2 commit_3 met bestand function_3 en inhoud: Function 3 commit_4 met bestand function_4 en inhoud: Function 4 Als we vervolgens de lijst met commits controleren: git log --oneline De console toont de volgende volgorde: d3efb82 (HEAD -> hypothesis) commit_4 c9f57b7 commit_3 c977f16 commit_2 4eb7cc3 (master) commit_1 Hier wordt de vlag --oneline gebruikt om de commitinformatie in verkorte vorm weer te geven. Een commit toevoegen aan de master-branch De laatste stap is om nog een commit toe te voegen aan de hoofdbranch master. Laten we daar naartoe schakelen: git checkout master De console bevestigt de overschakeling: Switched to branch 'master' Maak nu een nieuw bestand aan voor een extra functie: nano function_5 Met de volgende inhoud: Function 5 Indexeer de aangebrachte wijzigingen: git add . Maak vervolgens de nieuwe commit aan: git commit -m "commit_5" Als we de lijst met commits controleren: git log --oneline De master-branch heeft nu twee commits: 3df7a00 (HEAD -> master) commit_5 4eb7cc3 commit_1 Branches samenvoegen met git rebase Om een rebase uit te voeren, moet je eerst overschakelen naar de hypothesis-branch: git checkout hypothesis Voer vervolgens de rebase uit: git rebase master Daarna geeft de console een bericht weer dat de succesvolle rebase bevestigt: Successfully rebased and updated refs/heads/hypothesis. Controleer nu de lijst met commits: git log --oneline De console toont een lijst met de commits van beide branches in hun oorspronkelijke volgorde: 8ecfd58 (HEAD -> hypothesis) commit_4 f715aba commit_3 ee47470 commit_2 3df7a00 (master) commit_5 4eb7cc3 commit_1 De hypothesis-branch bevat nu de volledige geschiedenis van de repository. Conflicten oplossen Net als bij git merge kunnen er tijdens het gebruik van het git rebase-commando conflicten optreden die handmatig moeten worden opgelost. Laten we onze repository zo aanpassen dat we opzettelijk een rebase-conflict creëren. Maak een nieuw bestand in de hypothesis-branch: nano conflict Voeg de volgende tekst toe: There must be a conflict here! Indexeer de wijziging: git add . Maak de commit aan: git commit -m "conflict_1" Schakel nu over naar de master-branch: git checkout master Maak een vergelijkbaar bestand aan: nano conflict Met de volgende inhoud: There must NOT be a conflict here! Indexeer de wijziging: git add . Maak de commit aan: git commit -m "conflict_2" Open het aangemaakte bestand opnieuw: nano conflict Wijzig de inhoud in: There definitely must NOT be a conflict here! Indexeer opnieuw de wijzigingen: git add . Maak nog een commit: git commit -m "conflict_3" Schakel nu terug naar de hypothesis-branch: git checkout hypothesis Voer de rebase opnieuw uit: git rebase master De console zal een conflictmelding weergeven: Auto-merging conflict CONFLICT (add/add): Merge conflict in conflict error: could not apply 6003ed7... conflict_1 hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". Could not apply 6003ed7... conflict_1 Git stelt voor om het conflicterende bestand te bewerken, de wijzigingen te indexeren met git add en vervolgens de rebase voort te zetten met de optie --continue. Dat is precies wat we gaan doen: nano conflict Het bestand bevat twee conflicterende versies die tussen speciale markeringen staan: <<<<<<< HEAD There definitely must NOT be a conflict here! ======= There must be a conflict here! >>>>>>> 6003ed7 (conflict_1) Onze taak is om de onnodige delen te verwijderen en het bestand in te vullen met een uiteindelijke versie van de tekst: There must absolutely definitely unanimously NOT be any conflict here! Indexeer vervolgens de wijzigingen: git add . Ga verder met de rebase: git rebase --continue Daarna opent de console een teksteditor waarin wordt voorgesteld om het oorspronkelijke commitbericht te wijzigen van de commit waarin het conflict optrad: conflict_1 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # interactive rebase in progress; onto bd7aefc # Last commands done (4 commands done): # pick 8ecfd58 commit_4 # pick 6003ed7 conflict_1 # No commands remaining. # You are currently rebasing branch 'hypothesis' on 'bd7aefc'. # # Changes to be committed: # modified: conflict # De console zal vervolgens een bericht tonen dat bevestigt dat het rebase-proces succesvol is voltooid: [detached HEAD 482db49] conflict_1  1 file changed, 1 insertion(+), 1 deletion(-) Successfully rebased and updated refs/heads/hypothesis. Controleer nu de lijst met commits in de hypothesis-branch: git log --oneline Je zult de oorspronkelijke volgorde van alle aangebrachte wijzigingen zien: 482db49 (HEAD -> hypothesis) conflict_1 bd5d036 commit_4 407e245 commit_3 948b41c commit_2 bd7aefc (master) conflict_3 d98648d conflict_2 3df7a00 commit_5 4eb7cc3 commit_1 Merk op dat de commits conflict_2 en conflict_3, die in de master-branch zijn gemaakt, eerder in de geschiedenis verschijnen dan conflict_1. Dit geldt echter voor alle commits die in de master-branch zijn gemaakt. Rebase van een externe repository Naast het werken met lokale branches, kan rebasen ook worden uitgevoerd bij het ophalen van wijzigingen uit een externe repository. Om dit te doen, moet je de optie --rebase toevoegen aan het standaard pull-commando: git pull --rebase remote branch Waarbij: remote de externe repository is branch de externe branch is In wezen is deze pull-configuratie gelijk aan git rebase, behalve dat de wijzigingen (commits) die op de huidige branch worden toegepast afkomstig zijn uit de externe repository. Belangrijkste voordelen van Git Rebase Lineariteit  Het git rebase-commando maakt het mogelijk om een vrij lineaire geschiedenis van de doelbranch te vormen, bestaande uit opeenvolgende commits. Een dergelijke opeenvolging zonder vertakkingen maakt de geschiedenis gemakkelijker te begrijpen en te analyseren. Minder conflicten  Het uitvoeren van git rebase vooraf kan de kans op conflicten bij het samenvoegen van branches met git merge aanzienlijk verkleinen. Conflicten zijn gemakkelijker op te lossen in opeenvolgende commits dan in commits die zijn samengevoegd tot één enkele merge commit. Dit is vooral relevant bij het pushen van branches naar externe repositories. Nadelen van Git Rebase Wijziging van de geschiedenis  In tegenstelling tot merge, herschrijft rebase gedeeltelijk de geschiedenis van de doelbranch en verwijdert onnodige elementen uit de geschiedenis. Risico op fouten  De mogelijkheid om de commitgeschiedenis aanzienlijk te herstructureren kan leiden tot onherstelbare fouten in de repository. Dit betekent dat sommige gegevens permanent verloren kunnen gaan. Wanneer Git Rebase gebruiken Git rebase is bijzonder nuttig bij het werken aan kleine of individuele feature branches die uiteindelijk in een gedeelde hoofdbranch zullen worden samengevoegd. Het is ook uitstekend voor het schoon en lineair houden van de geschiedenis, wat vooral gunstig is bij open-sourceprojecten of wanneer je de commitgeschiedenis van een project moet behouden voor eenvoudig debuggen en beter begrip. In teamomgevingen met meerdere bijdragers moet rebase echter voorzichtig worden gebruikt om problemen te voorkomen die verband houden met het herschrijven van openbare geschiedenis. Het is belangrijk om met je team te communiceren over wanneer rebasen gepast is en ervoor te zorgen dat iedereen zich bewust is van het potentiële risico op conflicten. In veel gevallen kan het gebruik van git merge voor het integreren van branches veiliger en eenvoudiger zijn, vooral wanneer wordt gewerkt aan gedeelde branches of wanneer een niet-lineaire geschiedenis acceptabel is. Belangrijke overwegingen Herschrijven van de geschiedenis Een van de belangrijkste aspecten van git rebase is dat het de commitgeschiedenis herschrijft, wat betekent dat de SHA-1-hashes van de gerebaseerde commits veranderen. Dit kan problemen veroorzaken in samenwerkingsomgevingen, vooral wanneer je een branch rebase die al naar een gedeelde externe repository is gepusht. Het herschrijven van de geschiedenis kan leiden tot conflicten met andere ontwikkelaars die hun werk hebben gebaseerd op de vorige geschiedenis. Het kan ook problemen veroorzaken bij het pushen van de gerebaseerde branch, omdat de externe repository zal detecteren dat de lokale geschiedenis niet langer overeenkomt met de externe. Vermijd het rebasen van openbare branches Een veelgebruikte best practice is om te voorkomen dat je openbare branches rebase die al met anderen zijn gedeeld. Omdat rebase de commitgeschiedenis verandert, kan het rebasen van openbare branches waarop meerdere ontwikkelaars vertrouwen leiden tot uiteenlopende geschiedenissen, verwarring en moeilijk op te lossen mergeconflicten. Over het algemeen is git rebase het meest geschikt voor lokale branches of voor het voorbereiden van een feature branch op een definitieve samenvoeging in een hoofdbranch. Openbare branches, vooral die waar meerdere mensen aan werken, moeten meestal worden samengevoegd in plaats van gerebased. Potentiële conflicten Tijdens een rebase, als er conflicterende wijzigingen zijn in zowel de feature branch als de doelbranch, zal Git stoppen en vragen om het conflict handmatig op te lossen. Hoewel het oplossen van conflicten tijdens een rebase vergelijkbaar is met dat tijdens een merge, vereist rebasen dat je conflicten oplost voor elke commit die opnieuw moet worden toegepast, wat het proces vervelender kan maken, vooral bij grote feature branches. Zodra de conflicten zijn opgelost, kun je de rebase voortzetten met het commando git rebase --continue. Conclusie Het samenvoegen van twee branches met behulp van rebase, geïmplementeerd met het git rebase-commando, verschilt fundamenteel van de klassieke merge die wordt uitgevoerd met het git merge-commando. git merge verandert de commits van een branch in één enkele commit in een andere. git rebase verplaatst commits van de ene branch naar het einde van een andere terwijl de oorspronkelijke volgorde behouden blijft. Een vergelijkbaar rebase-effect kan ook worden bereikt door het gebruik van het git pull-commando met de extra optie --rebase. Aan de ene kant stelt het git rebase-commando je in staat een schonere en beter te begrijpen commitgeschiedenis te creëren in de hoofdbranch, wat de onderhoudbaarheid van de repository verhoogt. Aan de andere kant vermindert git rebase het detailniveau van de wijzigingen binnen de branch, vereenvoudigt de geschiedenis en verwijdert sommige van de vermeldingen. Om deze reden is rebasen een functie die bedoeld is voor meer ervaren gebruikers die begrijpen hoe Git werkt. Meestal wordt het git rebase-commando samen met het git merge-commando gebruikt, waardoor je een zo optimaal mogelijke repository- en branchstructuur kunt bereiken.