Git Remotes, Branches en Mergen

Herhaling¶

Gedistribueerd Versiebeheer¶

In het eerste hoofdstuk hebben we Git en GitHub al gebruikt en spraken we over gedistribueerd versiebeheer (Distributed Version Control). We komen hier eerst even wat dieper op dit concept terug.

Vergelijking met Gecentraliseerd¶

Traditioneel waren versiebeheersystemen gecentraliseerd (bvb. Subversion of svn). Dit wil zeggen dat alle versiegegevens enkel op een centrale server worden bijgehouden. De server wordt gebruikt tijdens vrijwel elke bewerking die een gebruiker uitvoert.

sequenceDiagram
    actor A as Dev A
    participant S as SVN Server
    actor B as Dev B

    S->>A: svn checkout project1:main
    S->>B: svn checkout project1:main
    S->>B: svn log
    S->>A: svn diff
    A->>S: svn commit
    A->>S: svn commit
    S->>B: svn update
    B->>S: svn commit

Het grote voordeel is dat dit conceptueel heel eenvoudig is. Daartegenover staan de beperkte flexibiliteit en netwerkafhankelijkheid. Veranderingen kunnen enkel op de server zelf in versiebeheer komen. Bijgevolg zijn veranderingen ook onmiddellijk 'zichtbaar' voor andere gebruikers.

Bij een gedistribueerd systeem, zoals Git, krijgt elke gebruiker een volledige kopie van de repository (inclusief alle commithistoriek, 'branches', metadata, enz.). We gebruiken dan ook de term clone i.p.v. checkout. Na het klonen gebeurt vrijwel elke bewerking nu lokaal.

sequenceDiagram
    actor A as Dev A
    participant S as Git Server
    actor B as Dev B

    S->>A: git clone project1
    S->>B: git clone project1
    B->>B: git log
    A->>A: git diff
    A->>A: git commit
    A->>A: git commit
    A->>S: git push
    B->>B: git commit
    S->>B: git pull

Het enorme voordeel hierbij is dat iedereen onafhankelijk en snel lokaal kan werken. De architectuur is ook extreem veilig omdat iedereen een volledige kopie van de repo heeft.

Het voornaamste nadeel is dat deze aanpak een stuk complexer kan zijn om te begrijpen met een wat steilere leercurve als gevolg.

Een repo clonen¶

GitHub is ongetwijfeld de bekendste Git server en bevat bovendien heel wat extra functionaliteit. Zo is bijvoorbeeld de volledige web interface geen standaard onderdeel van Git.

Om een Git repo te clonen (met de Git CLI) hebben we eerst en vooral een adres nodig. Git ondersteunt standaard twee protocollen om met de server te communiceren: HTTP(S) en SSH. SSH vereist enige voorkennis en extra configuratie. We kiezen dus doelbewust voor HTTP. Na het gebruik van GitHub Desktop in het eerste hoofdstuk zou bovendien authenticatie via HTTP al functioneel moeten zijn.

Op een GitHub-pagina kan je het Git-adres vinden door op de groene <> Code knop te klikken. Bijvoorbeeld vanaf deze eenvoudige test repo: https://github.com/dvx76/git-demo.

In dit geval dus https://github.com/dvx76/git-demo.git.

Om een repo te clonen gebruik je het git clone commando.

Op deze manier kan je elke (publieke) repo op GitHub lokaal clonen!

Remotes¶

$ mkdir ../foo
$ cd ../foo
$ git init
$ git remote add origin ../hello
$ git fetch
$ git pull
$ git remote -v
$ cd ../hello
$ rm -rf ../foo

Het git remote commando geeft een lijst met de gekende remote(s). Met de -v (verbose) optie krijg je voor elke remote ook de URL.

(De termen fetch en push komen zo meteen aan bod.)

Het git status commando kennen we al, maar het geeft nu wat extra informatie:

1. De lokale main branch is "gelinkt" met de main branch van de origin remote. We zeggen dat de lokale main branch de remote origin/main branch trackt (volgt).
2. De lokale en de remote branch zijn actueel (up-to-date).

Push¶

Met het git push commando worden aanpassingen op de lokale branch naar de remote verstuurd.

Eerst wordt een verandering gecommit. Veranderingen die nog niet gecommit zijn kan je dus nooit rechtstreeks pushen!

We gebruiken onze editor om iets aan te passen in hello.py (bvb. een module-docstring toe te voegen).

$ git commit -a -m "Add module docstring in hello.py"
[main 22b1b17] Add module docstring in hello.py
 1 file changed, 2 insertions(+)

Als we nu opnieuw git status uitvoeren zien we iets nieuws. De lokale branch "loopt voor" (is ahead) op de remote, en wel met 1 commit.

Zoals de output suggereert kan die commit met git push naar de remote verzonden worden.

Authenticatie

In principe niet meer nodig wegens het eerdere gebruik van GitHub Desktop.

Het is je misschien opgevallen dat we nooit hebben moeten inloggen. Dat komt omdat de repo die we clonen publiek is. Toegankelijk voor iedereen dus - ook zonder GitHub account! Er is dus geen authenticatie aan te pas gekomen.

Daarna hebben we lokaal een aanpassing gecommit en ook daar is nooit authenticatie voor nodig.

Nu willen we echter aanpassingen naar de repo op GitHub doorsturen (pushen). Dat kan natuurlijk niet door iedereen!

Omdat we een HTTP-remote gebruiken zou je in principe telkens (bij elk git push commando) authenticatiegegevens moeten ingeven. Omdat dit al snel erg vervelend zou worden kan Git werken met een zogenaamde credential helper om op een veilige manier je authenticatiegegevens lokaal te bewaren en hergebruiken.

Welke helper gebruikt wordt en hoe het authenticatieproces precies verloopt, hangt af van het besturingssysteem.

WindowsmacOSLinux

De Git Credential Manager (GCM) wordt automatisch (samen met de Git CLI) geïnstalleerd en gebruikt.

Wanneer je voor de eerste keer het git push commando gebruikt zal deze helper je voorstellen om via je browser in te loggen op GitHub. Vervolgens moet je in de browser de helper (Git Credential Manager) toegang verlenen tot je GitHub account. (Dit hele proces is gekend als OAuth 2.0 en krijg je misschien te zien tijdens de module Security)

Op macOS moet de Git Credential Manager apart geïnstalleerd worden. Dit doe je best via Homebrew.

brew install --cask git-credential-manager

Eenmaal geïnstalleerd kom je bij het eerste git push commando in hetzelfde "OAuth" scenario terecht als op Windows.

Op Linux hangen de mogelijkheden een beetje af van de gebruikte Linux distributie (en je eigen ervaring met het systeem).

Indien beschikbaar is het git-credentials-oauth package een goede optie.

sudo apt install git-credentials-oauth

git-credentials-oauth config

Hierna kom je bij het eerste git push commando in hetzelfde "OAuth" scenario terecht als op Windows.

In de git log --oneline output zien we de nieuwe commit, alsook de informatie dat deze commit de meest recente commit is, zowel in de lokale main branch als in de main branch van de origin remote.

Fetch en Pull¶

Stel dat een andere ontwikkelaar ook een lokale clone heeft van dezelfde repo, zonder deze nieuwe commit te hebben. Zijn of haar lokale repo ziet er dan als volgt uit:

Met het git fetch commando zullen alle veranderingen op de remote gedownload worden, maar lokale branches worden niet aangepast. Dit wordt iets duidelijker als we daarna ook git status uitvoeren.

Met het commando git merge (samenvoegen) worden de veranderingen in de lokale kopie van de remote branch opgenomen in de lokale branch.

Meestal wil je zowel fetchen als mergen. Dit kan met één enkel commando: git pull.

Van de lokale repo naar GitHub¶

In het eerste hoofdstuk hebben we een GitHub account gemaakt en een repo rechtstreeks op GitHub aangemaakt.

In het volgende deel hebben we met de Git CLI een volledig lokale repo (hello) gemaakt. We willen nu die repo ook op GitHub krijgen.

Een 'lege' GitHub repo toevoegen¶

Ingelogd op github.com kan je een nieuwe repository maken via de knop rechts bovenaan.

Hoewel dit niet verplicht is, werkt het handiger als de namen van de lokale en de remote repo hetzelfde zijn, dus we gebruiken gewoon hello.

Voor de visibility behouden we Public. Op die manier kunnen we elkaars repos bekijken.

Omdat we al een lokale repo hebben die we later hierheen willen pushen kiezen we ervoor geen initiële README, .gitignore of andere bestanden in de repo te plaatsen. We starten dus met een volledig lege repo (geen commits).

Als de repo is aangemaakt krijgen we van GitHub meteen de juiste commando's om de repo als remote toe te voegen aan onze lokale repo.

Remote toevoegen en pushen¶

We bekijken de commando's die GitHub voorstelt één voor één.

git remote add origin https://github.com/dvx76/hello.git

Hiermee voegen we een remote toe en geven deze de naam origin. Het resultaat is dan eigenlijk hetzelfde als wanneer je een remote clonet.

git branch -M main

Met -M move (verander) je de naam van de huidige branch naar een nieuwe naam. Omdat onze (enige) branch al main heet doet dit commando niets en kunnen we het overslaan.

git push -u origin main

Hiermee pushen we de huidige lokale branch (main) naar de main branch van de origin remote. Als we enkel git push gebruiken weet Git niet waarnaar we precies willen pushen.

Met -u (upstream) stellen we in dat dit de upstream (= op een remote) branch is van onze lokale branch. Als we -u niet gebruiken moeten we telkens opnieuw origin main meegeven. Hierdoor kunnen we de volgende keer gewoon git push gebruiken, want Git weet nu dat origin main de juiste remote branch is.

Oefening¶

1. Volg de stappen uit dit hoofdstuk om een lege hello repo te maken op je GitHub account.
2. Stel deze repo in als origin van je lokale hello repo.
3. Push naar de remote.
4. Bekijk de repo in GitHub om te bevestigen dat de push gelukt is.

Branching en de Commit Tree¶

Commits¶

Een commit is eerder beschreven als iets dat de volgende informatie bevat:

• Een ID
• Auteur
• Datum
• Beschrijving
• Diff

Daarnaast bevat elke commit (behalve de allereerste commit) ook de ID van de voorgaande commit (we spreken van parent commit). In speciale gevallen kan een commit zelf meerdere parents hebben.

Commit Hash¶

We spreken ook wel van een commit hash i.p.v. ID omdat het de hash-waarde is van alle informatie in de commit. Een hash is een wiskundige functie die voor een bepaalde input een unieke string met vaste lengte (hier 40 karakters) geeft. Naast het identificeren van een bepaalde commit zorgt die hash vooral voor de data-integriteit van Git: door de hash opnieuw te berekenen kan Git datacorruptie detecteren! Omdat de gebruikte hashfunctie SHA-1 is wordt er soms ook gesproken over een commit sha.

Op https://www.shasum.com kan je zelf het berekenen van een SHA1 hash uitproberen. Voer wat tekst in (bvb. de inhoud van hello.py) en bekijk de hash. Pas dan één karakter aan en herbekijk de hash. Wat valt op?

Om naar een bepaalde commit te refereren gebruiken we de commit hash. We hoeven niet de volledige hash van 40 karakters te gebruiken. Het begin van de hash is genoeg om een bepaalde commit uniek te identificeren. In onze kleine repo met slechts een handvol commits hebben we al genoeg met de eerste 7 karakters. Dat doet het Git-commando zelf ook, bvb. bij git log --oneline.

Commit Diff¶

Dat een commit de diff met zijn parent bevat, is eigenlijk niet helemaal correct. Git bewaart elke versie van elk bestand. I.p.v. een diff bevat een commit dan eigenlijk een lijst van bestandsversies. Elke commit vormt op die manier een complete snapshot van je repo. Vele andere versiebeheersystemen werken precies omgekeerd en bewaren bij elke commit de diffs.

De diff die je te zien krijgt als je een commit bekijkt, wordt dus eigenlijk bepaald door die commit met zijn parent te vergelijken.

index e0f8470..13b7d2a 100644

Een ketting van commits¶

Omdat elke commit de ID van de vorige commit bevat, krijgen we dus een soort ketting van commits. We halen er opnieuw de output van git log --oneline bij:

Deze kunnen we grafisch voorstellen als een tijdlijn. De oudste commit links en de laatste commit rechts:

Branches¶

Een branch in Git is gewoon een vertakking van de tijdlijn van je code. Je gebruikt branches zodat je veilig en overzichtelijk kan werken:

• Isolatie – je kan nieuwe features of fixes uitproberen zonder de stabiele code te breken.
• Samenwerken – meerdere mensen (of AI agents) kunnen tegelijk aan verschillende dingen werken zonder elkaar in de weg te zitten.
• Experimenteren – je kan ideeën testen, en als het niets is, gooi je de branch gewoon weg.

"Refs" en de main branch¶

Conceptueel is een branch een welbepaalde reeks commits. Zoals de naam al doet vermoeden kunnen er meerdere branches (vertakkingen) zijn en vormen ze samen een tree (boom) of graph.

$ git config --global init.defaultBranch main

Omdat elke commit naar zijn voorganger (parent) verwijst hoeft Git voor een branch eigenlijk enkel te onthouden wat de laatste commit is voor die branch. Git gebruikt hiervoor references (of kort: refs).

Daarom zien we in de output van git log --oneline by the laatste commit main staan (en ook origin/main aangezien ook op de remote dit de laatste commit is op de main branch).

HEAD¶

In diezelfde output zien we ook dit staan: HEAD -> main.

HEAD is een speciale reference en verwijst normaal gezien naar de naam van de huidige branch.

Branches maken¶

Tot nu toe hebben we enkel op de default of main branch gewerkt. Een nieuwe branch kan op twee manieren gemaakt worden:

• git branch <name> maakt een nieuwe branch maar blijft op de huidige branch in de working directory
• git switch -c <name> maakt (-c = create) een nieuwe branch en switcht ook naar die branch

Met git status kunnen we controleren op welke branch we momenteel werken. Met git switch (zonder -c) kunnen we switchen naar een andere (bestaande) branch. Met git branch krijgen we een lijst met alle branches. Voegen we -a toe, dan krijgen we ook de gekende remote branches.

Merk op dat er intern in de Git repo weinig veranderd is! Er zijn twee refs gemaakt voor de twee nieuwe branches en beide verwijzen naar dezelfde commit, namelijk de commit waarnaar ook de main branch verwijst. Een nieuwe branch "start" dus altijd vanaf de commit waar de huidige branch naar verwijst.

ref: refs/heads/cool-feature

22b1b17cd1b19d5da6f451fe3b066aee2dc0620d

22b1b17cd1b19d5da6f451fe3b066aee2dc0620d

22b1b17cd1b19d5da6f451fe3b066aee2dc0620d

Branches en Commits¶

Als we nu een nieuwe commit aanmaken terwijl we op een andere branch werken, gebeurt er het volgende:

1. De nieuwe commit verwijst (parent) naar de vorige commit van de branch.
2. De branch reference wordt aangepast en verwijst nu naar de nieuwste commit.
3. De HEAD ref wordt op dezelfde manier aangepast. Alle andere refs veranderen niet.

Na aanmaken van een nieuw bestand:

# Tests for the hello module

Nog geen boom¶

We hebben nog steeds niet echt een "boomstructuur" met onze commits.

Als we aanpassingen committen op de another-feature branch, dan komt daar verandering in.

Oefeningen¶

1. Clone de repo van https://github.com/dvx76/git-this.
2. Bekijk de lijst met branches.
3. Bekijk voor elke branch de lijst met commits.
4. Probeer op een blad papier de volledige commit tree uit te tekenen.
5. Simuleer wat er gebeurt met https://dvx76.github.io/explain-git-with-d3/, en/of maak level 2 in de reeks Introduction Sequence op https://learngitbranching.js.org/.

Mergen¶

De aanpassingen (commits) op een branch zullen in principe op een bepaald moment naar de main branch gebracht moeten worden. Dit proces heet mergen (samenvoegen).

Bij een merge spreken we altijd over:

• Een source branch - dit is de branch met de commits die op een andere branch terecht moeten komen
• Een target branch

De source branch wordt in de target branch gemerged. De commit waar de twee branches uit elkaar lopen (divergeren), noemen we het branchpunt (branchpoint), of merge base (most recent common ancestor).

Kijken we terug naar de laatste visualisatie uit het vorige hoofdstuk: als we de cool-feature branch in de main branch willen mergen, dan is:

• cool-feature de source branch
• main de target branch
• 22b1b17 de merge base

Om te mergen gebruiken we het git merge commando, met als parameter de source branch. Het commando wordt uitgevoerd vanop de target branch.

Er zijn drie basisscenario's die zich bij een merge kunnen voordoen:

1. Fast-Forward Merge
2. True (of three-way) Merge
3. Merge Conflict

Fast-Forward Merge¶

Een fast-forward merge is de eenvoudigste vorm. Dit komt voor als er op de target branch geen nieuwe commits zijn na het branchpunt.

Het volgende voorbeeld merget de cool-feature branch in de main branch.

explain-git-with-d3 kan de operatie duidelijker in beeld brengen.

Nadat de cool-feature branch in main gemerged is, hebben we de branch niet meer nodig. Een branch deleten doe je met git branch -d. Git weet welke branches al gemerged zijn. Als je een niet-gemergede branch probeert te deleten, krijg je een foutmelding!

True (three-way) Merge¶

Wat gebeurt er als er vanaf het branchpunt (de aftakking) nieuwe commits zijn op zowel de source branch als de target branch? In dit geval kan Git niet zomaar de source branch ref aanpassen, want dan zouden we de tussenliggende commits op de source branch verliezen.

Na de vorige fast-forward merge zitten we eigenlijk al in die situatie!

Dan mergen we de another-feature branch in de main branch.

Git opent nu de teksteditor om een nieuwe commit message te schrijven! Standaard zal dit Merge branch 'another-feature' zijn en dit kunnen we zo laten. Met de --no-edit optie kunnen we de voorgestelde commit message direct aanvaarden.

Wat is er gebeurd?

Omdat er een commit is op de main branch ("voorbij" het another-feature branchpoint) kan Git niet gewoon een fast-forward merge gebruiken en "doorspoelen" naar de laatste commit op de another-feature branch.

Om de aanpassingen van de another-feature branch op de main branch te krijgen, worden die aanpassingen (commits) één voor één (in volgorde) toegepast op de main branch. Op het einde worden alle aanpassingen samen vastgelegd in een nieuwe commit op de main branch. Dit noemen we een merge commit. Die commit bevat dus alle aanpassingen van alle commits van de another-feature branch.

Die merge commit krijgt ook twee parent commits: de vorige commit van de main branch en de laatste commit van de another-feature branch. Op die manier blijft het achteraf duidelijk wat er precies gebeurd is. Alle commits op de another-feature branch blijven bestaan (ook als we die branch deleten!).

De commit graph ziet er nu zo uit:

Opnieuw kan een simulatie met explain-git-with-d3 een beter beeld geven van wat er precies gebeurt.

Merge Conflicts¶

Deze derde en laatste mogelijkheid is eigenlijk een speciaal geval van de vorige three-way merge. Zoals de naam doet vermoeden gaat het hier om de situatie waarin er tussen de source branch en de target branch conflicten zijn die Git niet automatisch kan oplossen.

We starten een nieuwe branch, feature-42. In een eerste commit passen we goodbye.py aan:

def say_goodbye():
    print("Goodbye")

In een tweede commit passen we hello.py aan:

"""Print a message to stdout."""
from goodbye import say_goodbye

message = "Hello from my first Git repo"
print(message)
say_goodbye()

Terwijl er aan deze feature werd gewerkt, is hello.py op de main branch ook aangepast in een nieuwe commit:

"""Print a message to stdout."""

message = "Hello from my first Git repo"
print(message)
print("Goodbye and thanks for all the fish!")

De commit graph ziet er nu zo uit (de oudere commits laten we voor de duidelijkheid achterwege):

Tot zover geen verschillen met een gewone merge. Als we nu echter de feature-42 branch willen mergen in main, krijgen we het volgende probleem:

Git kon er niet in slagen de commits van feature-42 automatisch te mergen in main. Op dat moment stopt Git met de merge en geeft de controle terug aan jou om het probleem (conflict) op te lossen. Er wordt ook aangegeven in welk bestand (of welke bestanden) er problemen zijn.

Dit is typisch een van de momenten waarop nieuwe Git-gebruikers in paniek raken. De situatie is echter meestal vrij eenvoudig op te lossen en zoals gewoonlijk wijst git status je onmiddellijk de weg.

Als we het bestand in kwestie nu bekijken zien we het volgende:

"""Print a message to stdout."""
from goodbye import say_goodbye

message = "Hello from my first Git repo"
print(message)
<<<<<<< HEAD
print("Goodbye and thanks for all the fish!")
=======
say_goodbye()
>>>>>>> feature-42

Dit is de manier waarop Git aangeeft waar er in het bestand een conflict is, en wat het conflict precies is. Elk blok tussen <<<<<<< en >>>>>>> is één conflict dat opgelost moet worden. Tussen <<<<<<< en ======= zien we de code zoals die bestaat op de target branch. Tussen ======= en >>>>>>> staat de code uit de source branch.

Het is nu aan ons om te beslissen hoe we dit willen oplossen. Uit de source branch blijkt dat we nu een functie willen gebruiken uit de goodbye module, dus we passen hello.py als volgt aan:

"""Print a message to stdout."""
from goodbye import say_goodbye

message = "Hello from my first Git repo"
print(message)
say_goodbye()

Maar nu zijn we de aanpassingen aan de oorspronkelijke tekst kwijt. Om hetzelfde resultaat te behouden passen we ook goodbye.py aan:

def say_goodbye():
    print("Goodbye and thanks for all the fish!")

Onze status ziet er nu als volgt uit:

Rest nog: alle aanpassingen samen committen in een merge-commit. Hierbij krijgen we opnieuw een voorgestelde commit message in de editor, net zoals bij een gewone merge.

$ git commit -a

De uiteindelijke commit graph ziet er dan net zo uit als na een gewone three-way merge.

Oefening¶

1. Clone de repo van https://github.com/dvx76/git-this
2. Bekijk de commit history
3. Merge de branch more-cities in main
4. Merge de branch strings-doc in improve-strings
5. Merge de branch bigfloat in improve-floats
6. Extra: Welke branches hebben commits die nog niet op main bestaan? Merge deze branches in main.

Samenvatting¶

git clone <url>

git remote add origin <url>

git remote -v

git pull

git push
git push -u origin main

git merge

git branch <naam>
git switch -c <naam>
git switch <naam>