Main en Master Branch in Git: wat is het en waarom is de hoofdtak nodig

Wat is Main / Master Branch in Git

Main Branch (of Master — afhankelijk van de repository-instellingen) — is de standaardtak die wordt aangemaakt bij het initialiseren van elke Git-repository. Het is de hoofdtak van het project en bevat code die klaar is voor implementatie in productie.

In tegenstelling tot develop, waar dagelijks werk aan nieuwe functies plaatsvindt, is main de etalage van het project. Elke codeversie in main heeft een volledige cyclus doorlopen: ontwikkeling in een feature-tak, integratie in develop, releasevoorbereiding in een release-tak en definitieve tests. Pas daarna komen wijzigingen in main terecht.

Belangrijkste principe: main moet altijd stabiel zijn. Als er een fout in main wordt ontdekt, betekent dit een dringende hotfix die buiten de planning om moet worden uitgebracht. Daarom wordt main in professionele projecten beschermd tegen onbedoelde wijzigingen door branch protection rules.

Volgens Git Book is main geen speciale tak met bijzondere eigenschappen, maar een gewone verwijzing naar een commit die volgens afspraak als hoofd wordt beschouwd. Git maakt op systeemniveau geen onderscheid tussen main en een andere tak.

Overstap van master naar main

Historisch gezien heette de standaard Git-tak master. In juni 2020 vestigde de Black Lives Matter-beweging de aandacht op de termen master en slave in de IT-industrie. GitHub kondigde de overstap naar de term main voor de standaard tak aan.

Sinds oktober 2020 worden alle nieuwe repositories op GitHub aangemaakt met de tak main. GitLab en Bitbucket hebben ook ondersteuning voor main als standaardnaam geïmplementeerd. Git 2.28 (juli 2020) voegde de optie init.defaultBranch toe voor het configureren van de standaard taknaam.

Technisch gezien is het hernoemen van een bestaande tak van master naar main een eenvoudige operatie. De grootste uitdaging is het bijwerken van alle verwijzingen in CI/CD-configuraties, documentatie en lokale repositories van ontwikkelaars.

Voer het volgende uit om een tak in een bestaande repository te hernoemen:

# Lokale hernoeming van master naar main
git branch -m master main

# Bijwerken van de externe repository
git push -u origin main

# Verwijderen van oude master op de server
git push origin --delete master

# Bijwerken van HEAD op de server
# (via GitHub webinterface: Settings → Branches → Default branch)

Rol van main in Git Flow en GitHub Flow

Git Flow en GitHub Flow definiëren de rol van de main-tak verschillend. De keuze van het model hangt af van de teamgrootte, releasefrequentie en vereisten voor codestabiliteit.

Voor mobiele ontwikkeling is Git Flow de standaard, omdat het publiceren van apps in de App Store en Google Play vaste releasecycli heeft. GitHub Flow is meer geschikt voor webprojecten met de mogelijkheid om meerdere keren per dag te implementeren.

GitHub Flow — vereenvoudigde aanpak

In GitHub Flow is er geen develop-tak. Alle feature-takken worden rechtstreeks vanuit main aangemaakt en na voltooiing via een Pull Request terug samengevoegd. Elke samenvoeging in main start automatisch een implementatie naar productie. Dit model vereist een hoge mate van testautomatisering en teamdiscipline.

In GitHub Flow is er geen develop-tak. Alle feature-takken worden rechtstreeks vanuit main aangemaakt en na voltooiing via een Pull Request terug samengevoegd. Elke samenvoeging in main start automatisch een implementatie naar productie. Dit model vereist een hoge mate van testautomatisering en teamdiscipline.

Bescherming van de main-tak

Branch protection voor main — een verplichte instelling in elk commercieel project. Zonder dit kan een onbedoelde push onvoltooide code naar productie sturen of een werkende applicatie verpesten voor alle gebruikers.

• Require pull request — directe push naar main is verboden. Alle wijzigingen via PR met review.
• Require approvals — minimaal 2 goedkeuringen voor samenvoeging in main (in geval van een fout van één reviewer).
• Require status checks — alle CI/CD-controles moeten succesvol zijn vóór samenvoeging.
• Require up-to-date — PR moet gebaseerd zijn op de laatste commit van main.
• Include administrators — bescherming geldt ook voor repository-eigenaren.
• Require signed commits — alle commits in main moeten zijn ondertekend met een GPG-sleutel.

Het configureren van alle zes regels — standaard voor mobiele projecten met een publiek van 10.000+ gebruikers. Voor kleine projecten zijn de eerste drie regels voldoende.

Vergelijking van beschermingsniveaus voor verschillende projecttypen

Het beschermingsniveau van main hangt af van de schaal van het project. Een startup kan rondkomen met minimale bescherming, terwijl een enterprise-applicatie maximale beperkingen vereist.

Releases en tags in main

Taggen (tagging) — de praktijk van het maken van benoemde verwijzingen naar specifieke commits in main. Elke tag komt overeen met een versie van de applicatie die naar productie is uitgebracht. Dit maakt het mogelijk om snel naar een eerdere release te schakelen voor debugging of een patch.

De standaard voor het benoemen van tags in mobiele ontwikkeling — SemVer (Semantic Versioning): v1.2.3, waarbij het eerste nummer de majorversie is (breaking changes), het tweede — minor (nieuwe functies), het derde — patch (correcties).

Een tag wordt aangemaakt na het samenvoegen van de release-tak in main. Deze commit wordt vervolgens gebouwd in CI/CD, ondertekend en naar de app store verzonden. Als er een fout in de tag wordt ontdekt, wordt er een hotfix-tak gemaakt vanaf die tag.

# Aanmaken van een geannoteerde releasetag
git tag -a v2.4.1 -m "Release version 2.4.1"

# Tag naar server verzenden
git push origin v2.4.1

# Alle tags in de repository bekijken
git tag -l "v2.*"

# Aanmaken van een hotfix-tak vanaf een specifieke tag
git checkout -b hotfix/crash-fix v2.4.1

Hiërarchie van Git Flow-takken

Inzicht in de takhiërarchie in Git Flow — de basis voor een correcte organisatie van gezamenlijke ontwikkeling. Elk taktype heeft zijn eigen bron, doel en samenvoegingsregels.

• Main (niveau 1) — de hoofdtak, bevat alleen releaseversies. Wordt aangemaakt bij initialisatie van de repository.
• Develop (niveau 2) — wordt aan het begin van het project vanuit main aangemaakt. Bevat de integratiecode van alle functies.
• Feature (niveau 3) — worden vanuit develop aangemaakt. Geïsoleerde ontwikkeling van afzonderlijke functies.
• Release (niveau 2) — wordt vanuit develop aangemaakt. Voorbereiding van een specifieke release voor publicatie.
• Hotfix (niveau 2) — wordt vanuit main aangemaakt. Spoedige correctie van kritieke productiefouten.

Belangrijke regel: feature wordt nooit rechtstreeks in main samengevoegd. feature → develop → release → main — de juiste samenvoegingsketen. Het overtreden van deze regel ontneemt het hele Git Flow-model zijn betekenis.

Voorbeelden van commando's voor main

Beschouw het scenario: het team heeft de voorbereiding van release v2.5.0 voltooid. De release-tak is gecontroleerd en klaar om in main te worden samengevoegd. Na samenvoeging wordt een tag aangemaakt en wordt de release gepubliceerd.

# Overschakelen naar main en bijwerken
git checkout main
git pull origin main

# Samenvoegen van gecontroleerde release-tak
git merge --no-ff release/2.5.0

# Releasetag aanmaken
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Main en tag naar server verzenden
git push origin main --tags

De vlag --no-ff (no fast-forward) garandeert het aanmaken van een merge-commit, zelfs als de samenvoeging door eenvoudige verplaatsing van de aanwijzer had kunnen worden uitgevoerd. Dit bewaart de informatie dat de wijzigingen uit de release-tak komen, wat de analyse van de geschiedenis vereenvoudigt.

Werken met hotfix via main

Als er een kritieke fout in productie wordt ontdekt, verschilt het proces van een gewone release. Hotfix wordt vanuit main aangemaakt en na correctie zowel in main als in develop samengevoegd.

Als er een kritieke fout in productie wordt ontdekt, verschilt het proces van een gewone release. Hotfix wordt vanuit main aangemaakt en na correctie zowel in main als in develop samengevoegd.

# Aanmaken van hotfix-tak vanuit main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Herstellen en committen
git add src/fix/
git commit -m "Fix crash on login screen"

# Hotfix terug samenvoegen in main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Hotfix ook samenvoegen in develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Hotfix-tak verwijderen
git branch -d hotfix/2.5.1-crash-fix