Git(hub)
Sinds Augustus 2020 ondersteund GitHub geen wachtwoorden voor
git
. Zie https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token voor hoe je je op Linux kan aanmelden. Git op Windows ondersteund dit via GUI dialoog normaal.
Inleiding
Versiebeheer met Git is vandaag de dag een stukje onontbeerlijke kennis in DevOps. We schrijven meer en meer zelf stukjes configuratie, scripten en hele stukken code om onze servers te configureren en automatiseren. Uit de software wereld leren we al langer dat goed versie beheer een must is, in kader van DevOps leren we daardoor dus ook Git.
In een zoektocht naar tutorials en ander zelfstudiemateriaal bots je echter vrij snel op specifieke terminologie, tientallen commando’s met talloze opties, verschillende workflows, … Resultaat: je ziet de bomen niet meer door het bos.
Starten met Git zal in het begin dus wellicht moeilijk lijken, maar hopelijk helpt deze inleidende cursus je snel op weg. Ik verwijs hierbij ook graag naar een (waarheidsgetrouwe) quote van Meghan Nelson[1]:
“The more you use git, the more comfortable you’ll … git with it!”
Git leer je niet in een dag, maar als je de stappen zet goed nakijkt wat je doet en op tijd hulp vraagt dan komt het zeker in orde!
In deze cursus behandelen we enkel de basis van Git.
Na een korte introductie in versiebeheer en Git(Hub) worden de nodige begrippen en commando’s geïntroduceerd aan de hand van een educatief, concreet mini-webproject met 2 personen. We beperken ons hierbij tot de zogenoemde basic[2] of centralized workflow[3] (met enkel een master/main branch). Deze workflow is geschikt voor beginners en/of kleine teams, en vereist slechts een gedeeltelijke kennis van de Git-materie.
Moeilijkere workflows worden verder kort behandeld, maar hopelijk liggen deze na het verwerken van de basiskennis in deze cursus beter/sneller binnen je bereik.
We eindigen met een aantal referenties en een cheat sheet met de meest gangbare commando’s in onze basic workflow.
De term main en master branch kom je nog vaak door elkaar tegen. De term “master” in 2021 nog gebruiken is not done, maar je komt hem vaak nog tegen in materie (als ook oudere screenshots in deze cursus). Houd zeker in het achterhoofd dat dit enkel een naamswijziging is zonder techniche veranderingen.
Deze cursustekst komt origineel uit Webdesign met HTML5 en is licht aangepast aan de cursus DevOps.
Er wordt veelvuldig gebruik gemaakt van (vernederlandste) Engelse terminologie en we gebruiken de symbolen.
Er wordt veelvuldig gebruik gemaakt van (vernederlandste) Engelse terminologie en we gebruiken de symbolen
voor een opmerking en voor een tip.
Veel lees- en Git-plezier!
Versiebeheer: wat, waarom en hoe?
Versiebeheer: wat?
Met versiebeheer bedoelen we elk systeem dat alle wijzigingen aan een verzameling van computerbestanden bewaart, zodat:
- meerdere gebruikers gelijktijdig wijzigingen kunnen aanbrengen aan deze bestanden (zelfs aan het zelfde bestand);
- wijzigingen kunnen worden vergeleken, samengevoegd en hersteld/teruggedraaid.
Versiebeheer wordt het vaakst gebruikt in het kader van softwareontwikkeling in teamverband.
Versiebeheer: waarom?
Veronderstel dat je met een aantal programmeurs samen aan een project wil werken. Je kan zelf een soort versiebeheersysteem opzetten door de programmabestanden in de cloud (bijv. op Dropbox) op te slaan. Zo’n ‘amateuristisch’ systeem heeft echter zijn beperkingen:
- Gelijktijdig met verschillende programmeurs aan hetzelfde bestand werken is moeilijk, aangezien de verschillende versies achteraf manueel moeten worden samengevoegd.
- Om alle wijzigingen aan alle bestanden bij te kunnen bijhouden, verval je al snel in bestandsnamen als keuzeformulier-v3.php en indexFinalVersion.html, of neem je talloze kopieën van alle bestanden in folders met namen als Geteste versie (few bugs left) of Versie 2018 03 20 (bijna klaar). Bovendien is het nagenoeg onmogelijk om op deze manier bij te houden wie wat wanneer heeft aangepast.
Met een specifiek daarvoor ontworpen versiebeheersysteem (VCS = Version Control System) zijn deze problemen van de baan. Enkele belangrijke voordelen van zo’n VCS-systeem (bij het samen schrijven aan softwareprojecten) op een rij:
- duidelijk overzicht van alle gemaakte wijzigingen (wie, wat, wanneer)
- vorige, specifieke versies van bestanden zijn steeds beschikbaar
- waarschuwing bij conflicten, bijvoorbeeld bij het wijzigen van hetzelfde gedeelte van een bestand door verschillende gebruikers
- geen onnodige storage: enkel de gewijzigde bestanden worden meermaals bewaard, samen met een historiek van wijzigingen
- soort automatische back-up (bij gebruik van een cloud dienst als GitHub of GitLab)
Git versus GitHub
Git is een open source[4], gedistribueerd versiebeheersysteem (of softwarebroncode-managementsysteem) ontwikkeld door Linus Torvalds in 2005 voor het beheren van de Linux-kernel.
Software
Om met Git te kunnen werken op je pc, heb je software nodig. Je hebt daarbij de keuze uit GUI tools (zoals Sourcetree, GitHub Desktop, Tower, …) of je kan werken met een CLI (Command Line Interface). In deze cursus verkiezen wij het laatste omdat via de CLI alle mogelijkheden ter beschikking zijn (in tegenstelling tot in de grafische omgevingen). Bovendien leidt deze werkwijze tot een beter begrip van de Git-filosofie/technologie, waardoor het in principe eenvoudig zou moeten zijn om – indien gewenst – over te schakelen op een GUI-client naar voorkeur.
Ubuntu + WSL
Gebruikers van Linux hebben altijd een beetje geluk bij Git. Zij hebben namelijk al een bash shell op hun systeem.
sudo apt-get update
sudo apt-get install git
En je bent klaar!
macOS
macOS heeft via XCode een ingeboude Git client maar deze is echter verouderd. Je kan deze updaten via brew (opens new window).
In de Terminal app volg je de instructies van brew.sh (opens new window)op. Als brew werkt doe je:
brew install git
En je bent klaar!
Windows
Note
Dit staat hier ter referentie, aangezien we WSL gebruiken gaan we Git voor Windows voorlopig niet gebruiken om verwarring te voorkomen, maar weet wel dat dit een optie is!
Git kan je downloaden via https://git-scm.com/downloads (opens new window). In deze download bevindt zich de Git Bash (CLI), shell-integratie en 2 grafische tools.
Installeer met de standaard instellingen.
Git bash geeft je een bash shell op je windows systeem, deze shell is vaak voor onze DevOps tools makkelijker dan CMD of PowerShell!
GitHub
GitHub is een website/hosting service voor software, gebouwd rond het Git-versiebeheersysteem.
Er worden verschillende extra features aangeboden zoals wiki’s, social coding, project & team management, …
Alternatieven voor GitHub die gelijkaardige services bieden zijn Assembla, Bitbucket, Codebase, GitLab, …
GitHub-account
Maak een GitHub-account aan op https://github.com (opens new window). Vergeet niet om je mailadres te bevestigen (je ontvangt hiervoor een link via mail) om gebruik te kunnen maken van alle mogelijkheden!
Gebruik je Thomas More mailadres en vraag een upgrade van je account via https://education.github.com/ (opens new window). Naast een Pro GitHub account krijg je ook nog vele voordelen op andere websites.
Git: basic workflow
De basis van Git (terminologie, commando’s, het concept branches) is eigenlijk niet zo moeilijk om te doorgronden, als je je de moeite getroost om deze sectie[5] in detail door te nemen.
Basisterminologie en commando’s
Alles begint met een remote repository (meestal afgekort tot repo). Dit kan je vergelijken met een folder met daarin alle projectbestanden en de ganse historiek van wijzigingen (van deze bestanden). In deze cursustekst hosten we deze remote repo op GitHub.
Veronderstel dat er 2 programmeurs zijn die aan een project werken, nl. Alice en Bob[6]. Zij starten met het downloaden van een kopie van de remote projectrepository op hun pc. Dit proces wordt ook wel het clonen van de remote repo genoemd en wordt uitgevoerd met het Git-commando clone. Het resultaat is een kopie van de projectbestanden (ook de working tree genoemd), alsook een .git subfolder die de lokale repository (de historiek van alle bestanden) bevat. Deze map is niet bedoeld om gelezen te worden door mensen. Het Git commando gaat achterliggend hier alles regelen voor ons. Verwijder deze map ook niet want dit breekt je Git!
Veronderstel vervolgens dat Alice wijzigingen aanbrengt aan het projectbestand stijl.css[7]. Zij doet dit in haar (lokale) working tree.
Om dit gewijzigd bestand toe te voegen aan de lokale repository zijn er 2 acties nodig:
- Allereerst moet het gewijzigde bestand stijl.css worden toegevoegd aan de zogenaamde staging area of index. Dit gebeurt via het Git-commando add.
- Vervolgens wordt het bestand verplaatst van de staging area naar de lokale repo via het Git-commando commit en worden de wijzigingen lokaal bevestigd.
Je vraagt je misschien af wat het nut is van de staging area/index en de extra tussenstap die moet gebeuren. In de staging area worden alle bestanden bewaard die met een volgende commit moeten worden toegevoegd aan de lokale repo. Op die manier kunnen we in 1 commit een aantal (bij elkaar horende) wijzigingen tegelijkertijd doorvoeren.
De volgende actie die Alice onderneemt is het uploaden van de gecommitte wijzigingen in haar lokale repo naar de remote repository. Dit gebeurt met het Git-commando push.
Op dit moment zijn de lokale repo van Alice en de remote repo gesynchroniseerd en opnieuw aan elkaar gelijk.
Ondertussen heeft Bob het bestand index.html gewijzigd (in zijn working tree). Ook hij bevestigt deze wijzigingen door deze toe te voegen aan zijn lokale repository via de Git-commando’s add en commit.
Nu wil ook Bob zijn lokale repo uploaden naar/synchroniseren met de remote repo. Als hij dit echter probeert (met het Git-commando push), resulteert dit in een foutmelding. Git merkt immers op dat de remote repo wijzigingen bevat (van Alice) die zich nog niet in de lokale repo van Bob bevinden.
Bob moet op dit moment eerst deze verschillen (tussen de remote en zijn lokale repo) downloaden. Dit kan hij doen met het Git-commando pull.
Nu zijn de lokale repo van Bob en de remote repo opnieuw aan elkaar gelijk en kan Bob zijn wijzigingen aan index.html pushen.
De basiscommando’s in meer detail
In deze sectie baseren we ons in grote mate op het hierboven uitgewerkte scenario om de basiscommando’s van Git in detail te illustreren.
We leggen daarbij ook uit hoe bestanden (en de wijzigingen ervan) worden bewaard in Git. Deze kennis is belangrijk om Git ten volle te kunnen begrijpen en gebruiken.
Instellen van je identiteit (en default editor)
Vooraleer je met Git begint te werken, stel je best je identiteit (naam en email) in, zodat duidelijk is wie welke wijzigingen heeft aangebracht. Je gebruikt daarvoor de commando’s
git config --global user.name "Your Full Name"
git config --global user.email "email"
Tijdens de installatie is ook een editor gekozen die we later kunnen/zullen gebruiken (bij het ingeven van commentaar bij commits of bij het terugdraaien van commits). De default optie is de VIM-editor, maar desgewenst kan je ook opteren voor een alternatief. Zo kan je de klassieke Kladblok/Notepad-applicatie instellen als editor op Windows of nano
op Linux.
Windows:
git config --global core.editor notepad
Linux
git config --global core.editor nano
Opzetten van een startrepository (lokaal en remote)
In deze sectie wijken we een beetje af van het scenario uit de vorige sectie, waar we ervan uitgingen dat er al een remote repository bestond. Deze (remote repo) moet echter ooit door iemand aangemaakt worden, en deze stap illustreren we hieronder.
Je kan op verschillende manieren een remote repository aanmaken, waarbij het verschil zit in welke volgorde en hoe (via Git Bash of via GitHub) je de verschillende stappen uitvoert. De door ons gekozen volgorde lijkt ons het eenvoudigst voor beginners.
Opzetten van een lokale repository
We vertrekken van een heel eenvoudig project project_itf_git dat Alice heeft aangemaakt op haar computer, en waarvan zij een remote versie op Git(Hub) wil plaatsen om samen met Bob aan te werken. De folderinhoud van haar project is als volgt:
De folder css bevat het bestand stijl.css en de folder .idea bevat allerlei configuratiebestanden van de voor dit project door Alice gebruikte IDE (Integrated Development Environment) Webstorm.
Het is niet de bedoeling dat deze laatste folder (.idea) wordt opgenomen in de repository. Deze bestanden bevatten immers geen code en zijn enkel van toepassing voor Alice. Zij maakt daarom een tekstbestand .gitignore aan in de root van haar project. In dit bestand geeft ze met een speciale syntax[8] aan welke bestanden ze niet wenst op te nemen in de repository. Als Alice enkel de .idea-folder niet wenst op te nemen, ziet dit bestand er dus zo uit:
Je kan dit .gitignore-bestand later ook nog toevoegen/veranderen, maar je moet dan wel enkele bijkomende commando’s uitvoeren om bestanden die reeds in de repository zijn opgenomen (en die je vanaf dan wenst uit te sluiten) te verwijderen[9]. Het is dus ideaal als je op voorhand weet/goed nadenkt over welke bestanden je niet wenst op te nemen in de repo.
Naast een .gitignore-bestand kan je ook best een README.md-bestand aanmaken in de root van je project[10]. Dit markdown (opens new window)-bestand heeft opnieuw een specifieke syntax[11] en wordt door GitHub gebruikt op de startpagina van de remote repository. Voorlopig specifieert Alice enkel een titel (#) en 1 verduidelijkende paragraaf:
Na het toevoegen van deze 2 bestanden, is Alice klaar om van haar project een lokale repository te maken. Zij navigeert in Windows Verkenner naar de folder waar het project zich bevindt, klikt rechts op de folder en kiest voor Git Bash Here:
Een (minder handig) alternatief is om Git Bash gewoon te openen en in de bash te navigeren naar de juiste map. (Op Linux hebben we die handige knop jammergenoeg niet)
Het eerste wat Alice doet, is het initialiseren van deze folder als een (lege) Git-repository door middel van het commando git init. Dit commando initialiseert de .git subfolder en maakt een lokale branch aan met de naam master. In feite is deze master-branch gewoon een pointer die steeds naar de laatste commit verwijst (zie verder).
Daarna worden via het commando git add . alle bestanden (uitgezonderd deze die zijn uitgesloten via .gitignore) uit deze map toegevoegd aan de staging area, zodat ze klaar staan om op te worden genomen in de volgende (in dit geval de eerste) commit. De wildcard . duidt op de volledige folder, inclusief subfolders en bestanden die beginnen met .
Het is mogelijk dat je hierbij waarschuwingen krijgt over LF en CRLF, maar die mag je negeren[12].
Ten slotte moet Alice alle bestanden uit de staging area nog committen (opnemen in de lokale repository). Dit doet ze met het commando git commit -m “comment”, waarbij ze ook nuttig en betekenisvol commentaar kan voorzien.
Je mag je comment zowel tussen dubbele quotes (“”) als enkele quotes (”) plaatsen.
Als Alice het commando git commit intypt (zonder de optie -m mee te geven), wordt de default editor geopend om je commentaar in te geven.
We zoomen even in op wat er achter de schermen is gebeurd, waarbij we voor de eenvoud de bestanden .gitignore en README.md negeren en dus (even) veronderstellen dat ons project slechts uit 2 bestanden bestaat, nl. stijl.css en index.html. Git bewaart voor elke commit
- een uniek identificatienummer (~ een SHA checksum van alle bestanden in de commit)
- pointers (of verwijzingen) naar snapshots (ook wel blobs genoemd) van de specifieke bestanden in de commit. Ook voor deze pointers/verwijzingen worden unieke SHA checksums (van de specifieke bestanden) gebruikt.
Grafisch kan dit als volgt worden voorgesteld:
We zullen verder zien dat een Git-repository eigenlijk niet meer is dan zo’n reeks van commits die worden bewaard zoals hierboven beschreven. Een branch is een pointer die verwijst naar het einde van die reeks. De default branch wordt – zoals eerder aangehaald – meestal main genoemd.
Elke keer je een commit doet, zal deze main-branch worden aangepast (en schuift hij verder door naar de meeste recente commit).
Verder is er nog de pointer HEAD, die verwijst naar de lokale branch waar je je momenteel bevindt. Deze pointer wordt belangrijker als je met meerdere branches wil gaan werken. In deze cursus werken we met 1 branch en wijst HEAD gewoon naar (dezelfde commit als) main.
Opzetten van een remote repository
Alice wil van haar lokale repo een remote kopie maken op GitHub. Daarvoor meldt ze zich aan op GitHub en maakt ze een nieuwe (lege) remote repository aan met naam project_itf_git. Ze heeft reeds een .gitignore– en README-bestand, dus ze maakt de overeenkomstige, juiste keuzes:
Met het commando
git remote add <remote-name> <remote-url>
geeft Alice de net aangemaakte remote repo op GitHub een naam die ze kan gebruiken in Git Bash.
Als <remote-name> wordt bijna altijd origin gebruikt. Welke <remote-url> je moet gebruiken, wordt gesuggereerd op GitHub:
Ten slotte pusht Alice haar lokale repository naar GitHub via
git push -u <remote-name> <branch-name>
De <remote-name> is bijna altijd origin (zie hierboven), de <branch-name> is de naam van de lokale branch (main). Er wordt nu een gelijknamige main-branch aangemaakt in de remote repo. De optie -u zorgt voor een koppeling tussen de lokale en remote repo (zodat we in de toekomst enkel git push moeten gebruiken als commando).
TIP: gebruik altijd
git push
indien je dit bovenstaande moet uitvoeren geeft dit commando je letterlijk het juiste commando om te copy pasten!Het is mogelijk dat tijdens het pushen je GitHub-credentials worden gevraagd.
De remote repo is nu gelijk aan de lokale repo van Alice, zoals grafisch geïllustreerd in de figuur hieronder:
Als Alice met git status opvraagt in welke status de bestanden (in haar lokale repo) zich bevinden, wordt dit bevestigd: On branch main en Your branch is up to date with ‘origin/main’.
Als allerlaatste actie nodigt Alice Bob uit om met haar samen te werken aan deze remote repository via de GitHub-tab Settings, keuze Collaborators. Ze zoekt hierbij op de GitHub-gebruikersnaam van Bob.
Collaborators toevoegen via GitHub
Bob ontvangt een mail waarin hij de uitnodiging tot samenwerken moet bevestigen.
Clonen van een remote repository
Bob wil nu de remote repo (die Alice net heeft gemaakt) clonen in een lokale repository. Hij gebruikt daarvoor het commando
git clone <remote-url>
De lokale repository (kopie van de remote repository) komt in een automatisch aangemaakte folder met dezelfde naam als de remote repo (in dit geval project_itf_git).
Met het commando
git clone <remote-url> <local folder>
kan je zelf een lokale folder <local folder> opgeven waarin de clone moet terechtkomen. Ook deze folder wordt automatisch aangemaakt.
Navigeer eerst naar de juiste folder vooraleer je het clone-commando uitvoert.
Nu is ook de lokale repository van Bob gelijk aan de remote repository (en de lokale repo van Alice):
Wijzigen van bestand(en) in lokale en remote repository
Stagen en committen van lokaal gewijzigd bestand (Alice)
Het commando git status gaf ook de boodschap nothing to commit, working tree clean weer. Dit betekent dat Alice nog geen bestanden heeft gewijzigd (sinds het aanmaken van de repository).
Veronderstel nu dat Alice enkele wijzigingen aanbrengt aan het stijl.css bestand. Als ze vervolgens opnieuw de status controleert (via git status), kan ze aflezen dat stijl.css modified is maar dat dit bestand zich in haar working tree en nog niet in de staging area bevindt (Changes not staged for commit:).
Met het commando git diff
worden de verschillen van alle (hier slechts 1) gewijzigde bestanden getoond. Met git diff <file>
kan je de verschillen van een specifiek bestand opvragen. Je kan bij lange uitvoer met <spatiebalk> naar de volgende pagina, en met <q> kan je het bekijken van de verschillen beëindigen.
Gebruik het git diff
-commando op geregelde basis ter controle, telkens voor je gewijzigde bestanden gaat stagen (toevoegen aan de staging area).
De wijzigingen zijn ok, dus nu voegt Alice dit bestand toe aan de staging area met het commando git add <file>
. Als daarna de status opnieuw wordt opgevraagd, lezen we opnieuw af dat stijl.css modified is én dat dit bestand zich in Alice’s staging area bevindt (Changes to be committed:).
Het git add
-commando kent vele varianten door verschillende opties te gebruiken:
-
git add --all
voegt alle nieuwe/gewijzigde bestanden toe aan de staging area -
`git add css/*.css voegt alle nieuwe/gewijzigde CSS-bestanden in de map css toe aan de staging area, Git ondersteund bash globbing.
Ook op dit moment kan je (desgewenst) nog nakijken wat de verschillen zijn tussen (de bestanden in) de lokale repo en de staging area. Je gebruikt hiervoor de commando’s
git diff --staged
# of
git diff --staged <file>
Het is nu tijd om dit gewijzigd stijlbestand te committen (op te nemen in de lokale repo van Alice). Alice doet dit met het commando
git commit -m "comment"
Er bestaan richtlijnen om goede commit-commentaren/boodschappen te schrijven[13]. Kies alvast voor betekenisvol commentaar, geschreven in een gebiedende wijs.
Als je online op zoek gaat naar informatie over Git, zal je wellicht ook het commando\
git commit -a -m "comment"
We zoomen opnieuw even in op wat er nu precies gebeurt in de lokale repo van Alice.
Git berekent voor deze nieuwe commit opnieuw een unieke SHA checksum, en linkt deze commit met de initiële commit (via een pointer/verwijzing naar de vorige commit). De HEAD en main pointer schuiven op naar rechts en verwijzen nu naar de laatste commit.
Opnieuw worden ook SHA-pointers naar snapshots/blobs van de specifieke bestanden in de nieuwe commit bewaard.
Het bestand index.html is niet gewijzigd, en aldus verandert de pointer naar de overeenkomstige blob dan ook niet.
Het bestand stijl.css is wel gewijzigd. Daarom wordt er via een pointer verwezen naar een nieuw snapshot/blob van dit bestand.
Vaak worden de repositories compacter voorgesteld waar we de (huidige toestand van de) lokale repo van Alice en de remote repo weergeven.
Pushen van lokale repo naar remote repo (Alice)
We merken dat de lokale repo van Alice 1 commit voor ligt op de remote repo. Dit wordt bevestigd door de commando’s git status
(Your branch is ahead of ‘origin/main’ by 1 commit.) of git log
(waarover later nog meer).
Alice kan nu haar wijzigingen pushen naar de remote repo d.m.v. het commando git push
.
Op dit moment zijn de lokale repo van Alice en de remote repo opnieuw synchroon, wat bevestigd wordt door de uitvoer van de commando’s git status
en git log
.
Appendix: Cheat sheet voor basic workflow
# Aanmaken van lokale start repo
# _README.md_ en _.gitignore_ bestand aanmaken
git init
git add .
git commit -m "startbestanden"
# Pushen van lokale start repo naar remote repo
# remote repo aanmaken op GitHub*
git remote add origin https://github.com/...
git push -u origin main
# Clonen van remote repo
# Bash openen in gewenste folder
git clone https://github.com/...
# Gewijzigde bestanden stagen en committen
git add <file(s)>
git commit -m "comment"
# Lokale commits uploaden naar remote repo
git push
#Verschillen weergeven tussen versie in lokale repo en versie in working tree
git diff of git diff <file>
# Verschillen weergeven tussen versie in lokale repo en versie in staging area
git diff --staged*
# of
git diff --staged <file>
# Status (van working tree en staging area) weergeven
git status
Git: teamwork workflow
Je hebt nu al geleerd hoe je GitHub en Git kunt gebruiken om versiebeheer op je projecten te doen. In deze tutorial gaan we een stap verder en gebruiken we Git om in teamverband aan dezelfde codebase te werken.
Werken met “branches”
Nadat je het project hebt gecloned op je computer kunnen we beginnen te werken aan code veranderingen. We doen dit in branches. Branches, ook wel feature branches genoemd, maken een kopie van de hoofdcode die zich op de “main” branch bevindt. Het is een slechte gewoonte om direct naar de “main” branch te pushen als je in teams werkt. Een uitzondering op deze regel is de eerste commit.
In een branch kun je zoals gebruikelijk één of meer commits maken, deze geven de wijzigingen weer om een bepaald deel van de code toe te voegen. Om een nieuwe branch te maken kun je het volgende doen met Git
$ git branch <branch naam>
maartje-add-contact-page
kunnen zijn, merk op dat branchnamen geen spaties mogen bevatten!Takken maken doe je met git branch
. Na het aanmaken van de branch moet je overschakelen naar het gebruik van die branch. Dit kan gedaan worden met git checkout
.
$ git checkout [branch naam]
Je kunt nu zoals gewoonlijk werken en git add
en git commit
gebruiken om je wijzigingen vast te leggen. Je kunt git push
gebruiken als je op een branch zit om de branch naar GitHub te pushen
Een volledige workflow zou bijvoorbeeld zijn
git branch maartje-add-contact-page
git checkout maartje-add-contact-page
touch contact.html # voorbeeld verandering!!! geen onderdeel van de workflow
git add .
git commit -m "Een contactpagina gemaakt"
git push --set-upstream origin maartje-add-contact-page # eerste keer nodig, gebruik gewoon `git push` voor latere wijzigingen in de branch
Pull Requests
Pull requests, ook wel Merge Requests genoemd in andere Git oplossingen, zijn verzoeken die gedaan worden om code van een bepaalde branch samen te voegen in de “main” branch van het repository. Je kunt dit doen nadat je voor de eerste keer “git push” gedaan hebt, door naar de repository op Github te gaan en naar “Pull Requests” te gaan, hier kun je klikken op “New Pull Request”.