We plaatsen een cookie voor Google Analytics om onze website te verbeteren

Met een cookie kun je advertenties personaliseren. Wij hanteren echter de strikte regels van de Autoriteit Persoonsgegevens. Surfgedrag houden we niet bij en we achtervolgen je ook niet met reclame.

Met Git meer grip op versiebeheer!

Bij Antagonist hebben we het al eens over Git gehad, bijvoorbeeld in een artikel over SSH. Git is een versiebeheersysteem die programmeurs helpt om de verschillende versies van hun broncode beter te beheren. Maar wat betekent dit eigenlijk, wat los je ermee op en hoe gebruik je het? Dat en meer leg ik je graag uit!

Krijg met Git meer grip op versiebeheer!

Inhoud

Wat is een versiebeheersysteem?

Als je op de computer iets maakt, dan is het heel fijn om backups van oude versies te hebben. Dit kan van een website zijn, maar ook van iets heel anders, zoals een Photoshop-project of een blogartikel. Erg handig als je iets verkeerd doet of achteraf merkt dat een vorige versie eigenlijk toch beter was.

Ook als je met andere mensen samenwerkt, dan worden er vaak verschillende versies rondgemaild. Dit leidt al snel tot verwarring, want wat is nou precies de nieuwste versie? Als vervolgens meerdere personen in verschillende versies veranderingen gaan maken, dan is het overzicht gauw verloren.

Dit zijn allemaal redenen waarom je graag een versiebeheersysteem wil. Daarin wordt een geschiedenis van alle veranderingen bijgehouden, kun je aanpassingen met elkaar combineren of ze een naam geven. Zo kun je eenvoudig versies met elkaar vergelijken en zie je snel wie wat heeft gedaan.

Git is zo’n versiebeheersysteem, specifiek voor broncode. Het is gemaakt om code te beheren, maar kan ook worden gebruikt voor alle bestanden die uit platte tekst bestaan.

Git opzetten

Vergelijk je Git met andere versiebeheersystemen, dan is één van de eerste en belangrijkste verschillen die je kunt opmerken dat het lokaal werkt. Dit wil zeggen dat alle veranderingen die je maakt lokaal in een .git-folder worden bijgehouden. Het voordeel hiervan is dat je makkelijk offline kunt werken, zonder afhankelijk te zijn van een centrale plek.

Voordat je Git in je project kunt gebruiken, moet je het natuurlijk de juiste omgeving laten aanmaken. Dit heet een ‘repository’. Deze repository bevat dan de set van bestanden in je project en alle daarbij behorende wijzigingen. Het aanmaken van een repository kan op twee manieren.

1. Door een nieuwe repository aan te maken

Als je een nieuw project begint en er nog nergens een repository bestaat, dan zul je een nieuwe repository moeten aanmaken. Met het volgende commando draai je Git in je nieuwe projectfolder:

$ git init

2. Door een al bestaande repository te klonen

Als er ergens anders al een Git repository voor je project is, dan kun je deze ook klonen. Dit kun je doen met het volgende commando:

$ git clone <repo>

Hier is <repo> het adres van de repository die je wilt klonen. Vaak zal dit een HTTPS- of Git-URL zijn naar bijvoorbeeld GitHub of een andere Git-server. Het klonen van een repository maakt een nieuw mapje voor je project aan.

Na het aanmaken van de repository, is het handig om jouw naam en e-mail in te stellen. Zo weet Git wie welke wijziging maakt. Dit doe je als volgt:

$ git config --global user.name "Voornaam Achternaam"
$ git config --global user.email "voorbeeld@example.com"

De --global flag is niet verplicht, maar wel handig als je dit meteen voor al je projecten in wil stellen.

Branches in Git

Voordat we met het maken van wijzigingen en het delen van onze code kunnen beginnen, moet ik eerst een aantal dingen uitleggen over de interne structuur die Git bijhoudt. Behalve de geschiedenis behouden, biedt Git ook een hele hoop mogelijkheden om verschillende ‘takken’ bij te houden.

Hoe branches in Git werken.

In Git heet dit een branch. Net zoals er bij een boom een hoofdstam is waar takken van afsplitsen, heeft Git dat ook met alle verschillende versies. Er is een hoofdtak, die vaak master genoemd wordt. Naast deze hoofdtak kun je zijtakken maken. De wijzigingen op een zijtak blijven dan apart van de hoofdtak, totdat je besluit deze terug in te voegen.

Dit heeft als voordeel dat je onafhankelijk van andere wijzigingen nieuwe dingen kunt ontwikkelen of testen. Dit is vooral handig als je met meerdere mensen tegelijk aan een project werkt, zodat je wel ergens kan ontwikkelen, zonder dat je daarbij andere mensen in de weg zit.

Controleren op welke Git branch je zit

Om te kijken op welke branch je zit, kun je git status gebruiken. Behalve de branch laat dat ook zien welke bestanden je hebt aangepast en of je nog achter of voor loopt op een remote repository (als je die hebt ingesteld). Het resultaat kan er als volgt uitzien:

$ git status
On branch master
nothing to commit, working tree clean

In dit voorbeeld zit ik op de master branch en zijn er geen aangepaste bestanden. Om van branch te veranderen, kun je het volgende doen:

$ git checkout -b new_testing_branch

Dit maakt een nieuwe branch aan, genaamd new_testing_branch. Wil je naar een branch die al bestaat, dan kun je de -b weglaten. Die flag geeft aan dat Git een nieuwe branch moet maken.

Wijzigingen maken

Als we eenmaal op de goede branch zitten, kunnen we beginnen met het aanmaken van nieuwe wijzigingen. Dit begint door gewoon lekker bezig te gaan met wat je wou doen, bijvoorbeeld je nieuwe feature toevoegen. Je zult daarna zien dat er nu wijzigingen in het overzicht van git status staan.

Om deze wijzigingen in Git vast te leggen, moeten we eerst alle aanpassingen toevoegen die we willen vastleggen. Dit doen we met git add <file>, waar <file> ook een folder kan zijn. Omdat dit ook een folder kan zijn, kunnen we (bijvoorbeeld) gemakkelijk alle bestanden met git add . toevoegen. Als we alle wijzigingen hebben geselecteerd, dan kunnen we dit commiten met:

git commit -m "Een korte beschrijving van de wijziging"

Dit maakt een zogenaamde commit aan. Dit legt de geselecteerde wijzigingen vast in een commit. Nadat iets is gecommit, is het vastgelegd en permanent opgeslagen in de Git history. Nadat we één of meerdere commits hebben gemaakt, kunnen we met git log de geschiedenis bekijken. Daar vind je een lijst van alle commits op je huidige branch, met datum en naam van de auteur.

Je zult misschien merken dat er bij elke commit een willekeurige hexadecimale waarde lijkt te staan. Dit is de commit hash. Dit wordt in Git gebruikt als de identifier van een commit. Als je meer informatie over een specifieke commit wil, kun je met git diff <commit_hash> het verschil tussen je huidige staat en die commit zien.

Terug naar een oude versie?

Wil je naar een oude versie terug of een andere branch testen? Er zijn in Git meerdere opties om dit te doen. Met git checkout <commit hash of branch naam> kun je naar een specifieke versie overschakelen. Let wel: switch je naar een specifieke commit, dan zit je halverwege een branch. Dit maakt het lastig om nieuwe wijzigingen toe te voegen, omdat je niet meer op een branch zit.

Mocht je naar een specifieke commit terugwillen, dan kun je beter met git reset --hard <commit hash> de branch naar een oude commit resetten. Dit kun je ook op een nieuwe branch doen. Zo raak je niet de staat van je oude branch kwijt.

Soms kom je erachter dat een commit een nieuwe bug introduceert of dat een nieuwe toevoeging toch nog niet af was. Je kunt dan met git revert <commit hash> een specifieke commit terugdraaien. Dit voegt een nieuwe commit toe die een oude commit ongedaan maakt. Het voordeel in vergelijking met een reset is dat je geen geschiedenis verliest, omdat dit een nieuwe commit is.

Remotes

Vaak werk je met meerdere mensen aan een project en is daar ergens een centrale Git repository voor. Denk aan een eigen GitLab-server of een gehoste service, zoals GitHub. In Git-terminologie heet dit een remote.

Remotes in Git.

Als je jouw repository hebt aangemaakt door een al bestaande repository te klonen, dan staat deze remote al standaard ingesteld. Heb je een nieuwe repository aangemaakt? Dan moet je de remote nog instellen. Dit kan met git remote add origin <remote git url> waar origin de naam van de remote is.

Voor sommige remotes is authenticatie nodig, zeker als je jouw wijzigingen naar de remote wil pushen. Dit kan met een SSH keypair of met een gebruikersnaam en wachtwoord. Als je gebruik wilt maken van authenticatie via SSH keys, dan moet je die doorgaans eerst bij je Git-server registreren. Zo weet jouw Git-server welke keys toegang verlenen tot welke accounts.

Git gebruikt dezelfde keys als SSH
Raadpleeg onze SSH-handleiding voor uitleg.

Zodra je een remote hebt ingesteld, kun je met git pull en git push nieuwe code pullen of pushen. Zoals de naam al doet vermoeden, zorgt een pull ervoor dat je nieuwe code van de remote binnenhaalt en een push dat jij nieuwe code naar de remote upload.

Let wel op, als de versie op de remote nieuwer is dan jouw versie, dan kan het zijn dat een push niet lukt. Haal dan eerst deze nieuwe code op. Zodra jouw branch helemaal up-to-date is, kun je jouw nieuwe code ook pushen.

Git gebruiken om te deployen

Als je Git eenmaal helemaal in je werkzaamheden hebt opgenomen, kan het misschien verleidelijk zijn om op je webhostingpakket ook de Git repository in te stellen. Als je dan een nieuwe versie op je website wil uitrollen, hoef je alleen met Git de nieuwe code binnen te halen.

Pas hier echter mee op. Als je een Git repository in je /public_html/-map hebt staan, dan kan het zijn dat een kwaadwillende erbij kan door op jouw website naar /.git/ te browsen. Dit is dus niet een goed idee. Hoe je dit wel moet instellen, lees je in ons artikel met handige SSH-tips.

Tot slot

Hopelijk heb je zo een goed beeld gekregen van wat de voordelen van een versiebeheersysteem als Git zijn. Zoek je nog krachtige webhosting met SSH-toegang, automatische backups en gratis SSL? Bedenk je unieke domeinnaam, kies het pakket dat bij jou past en ga aan de slag!

Kies je hostingpakket →

P.S. Op de hoogte blijven van alle artikelen, updates, tips en trucs die op ons blog verschijnen? Volg ons via Facebook, Twitter, Instagram, RSS en e-mail!

Deel dit blog
Noah Goldsmid
Noah Goldsmid

Noah is als developer bij Antagonist werkzaam. Daar houdt hij zich bezig met het onderhouden en verbeteren van Mijn Antagonist; het administratief beheersysteem voor klanten en hun producten.

Artikelen: 2

3 reacties

  1. Leuk artikel! Ik zag alleen dat er op de hostingpakketten wel een hele oude versie van git staat (bij mij 1.7.1).
    Gaan jullie deze versie binnenkort updaten?

    • Hi David,

      Bedankt! Git 1.7.1 is de nieuwste versie die in de CloudLinux 6 repository zit, vandaar. We kiezen er bewust voor om een oudere, maar bewezen versie te draaien die stabiel en veilig is (dankzij backporting). Komt er een nieuwe versie beschikbaar in de repository, dan zullen we daar naar updaten.

      Met vriendelijke groet,

      Het Antagonist-team

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Sterren Webhosting: 5 sterren uit 5.830 reviews

60.000+ webhostingpakketten actief
Bij de beste webhosters in MT1000 en Emerce 100