Main och Master Branch i Git: vad det är och varför huvudgrenen behövs

Vad är Main / Master Branch i Git

Main Branch (eller Master — beroende på databasinställningar) — är standardgrenen som skapas vid initiering av varje Git-databas. Det är projektets huvudgren och innehåller kod redo för driftsättning i produktion.

Till skillnad från develop, där det dagliga arbetet med nya funktioner pågår, är main projektets skyltfönster. Varje kodversion i main har genomgått en fullständig cykel: utveckling i feature-gren, integration i develop, förberedelse av release i release-gren och slutlig testning. Först därefter kommer ändringarna in i main.

Nyckelprincip: main måste alltid vara stabil. Om ett fel upptäcks i main innebär det en akut hotfix som måste släppas utanför ordinarie schema. Därför skyddas main i professionella projekt mot oavsiktliga ändringar genom branch protection rules.

Enligt Git Book är main inte en speciell gren med särskilda egenskaper, utan en vanlig referens till en commit som enligt konvention anses vara huvudgrenen. Git gör inte skillnad mellan main och någon annan gren på systemnivå.

Övergång från master till main

Historiskt sett hette standardgrenen i Git master. I juni 2020 uppmärksammade Black Lives Matter-rörelsen termerna master och slave inom IT-branschen. GitHub tillkännagav övergången till termen main för standardgrenen.

Sedan oktober 2020 skapas alla nya databaser på GitHub med grenen main. GitLab och Bitbucket har också implementerat stöd för main som standardnamn. Git 2.28 (juli 2020) lade till alternativet init.defaultBranch för att konfigurera standardgrenens namn.

Tekniskt sett är det en enkel operation att byta namn på en befintlig gren från master till main. Den största utmaningen är att uppdatera alla referenser i CI/CD-konfigurationer, dokumentation och utvecklares lokala databaser.

För att byta namn på en gren i en befintlig databas, kör:

# Lokal omdöpning av master till main
git branch -m master main

# Uppdatering av fjärrdatabasen
git push -u origin main

# Borttagning av gamla master på servern
git push origin --delete master

# Uppdatering av HEAD på servern
# (via GitHub webbgränssnitt: Settings → Branches → Default branch)

Roll av main i Git Flow och GitHub Flow

Git Flow och GitHub Flow definierar main-grenens roll olika. Valet av modell beror på teamets storlek, releasefrekvens och krav på kodstabilitet.

För mobilapplikationsutveckling är standarden Git Flow, eftersom publicering av appar i App Store och Google Play har fasta releasecykler. GitHub Flow passar bättre för webbprojekt med möjlighet till driftsättning flera gånger om dagen.

GitHub Flow — förenklad metod

I GitHub Flow finns ingen develop-gren. Alla feature-grenar skapas direkt från main, och efter slutförande slås de samman via Pull Request. Varje sammanslagning i main utlöser automatiskt driftsättning till produktion. Denna modell kräver hög testautomatisering och teamdisciplin.

I GitHub Flow finns ingen develop-gren. Alla feature-grenar skapas direkt från main, och efter slutförande slås de samman via Pull Request. Varje sammanslagning i main utlöser automatiskt driftsättning till produktion. Denna modell kräver hög testautomatisering och teamdisciplin.

Skydd av main-grenen

Branch protection för main — en obligatorisk inställning i varje kommersiellt projekt. Utan det kan en oavsiktlig push skicka ofullständig kod till produktion eller förstöra en fungerande applikation för alla användare.

• Require pull request — direkt push till main är förbjuden. Alla ändringar via PR med granskning.
• Require approvals — minst 2 godkännanden för sammanslagning i main (om en granskare gör fel).
• Require status checks — alla CI/CD-kontroller måste vara framgångsrika före sammanslagning.
• Require up-to-date — PR måste baseras på den senaste commiten i main.
• Include administrators — skyddet gäller även ägare av databasen.
• Require signed commits — alla commits i main måste signeras med GPG-nyckel.

Konfigurering av alla sex regler — standard för mobilprojekt med 10 000+ användare. För små projekt räcker de första tre reglerna.

Jämförelse av skyddsnivåer för olika projekttyper

Skyddsnivån för main beror på projektets omfattning. En startup kan klara sig med minimalt skydd, medan en enterprise-applikation kräver maximala begränsningar.

Releaser och taggar i main

Taggning (tagging) — praxis att skapa namngivna referenser till specifika commits i main. Varje tagg motsvarar en version av applikationen som släppts till produktion. Detta möjliggör snabb växling till tidigare releaser för felsökning eller patch.

Standard för namngivning av taggar inom mobilutveckling — SemVer (Semantisk版本hantering): v1.2.3, där första numret är huvudversion (breaking changes), andra — mindre (nya funktioner), tredje — patch (korrigeringar).

En tagg skapas efter sammanslagning av release-grenen i main. Denna commit byggs sedan i CI/CD, signeras och skickas till appbutiken. Om ett fel upptäcks i taggen skapas en hotfix-gren från den taggen.

# Skapa annoterad releasetagg
git tag -a v2.4.1 -m "Release version 2.4.1"

# Skicka taggen till servern
git push origin v2.4.1

# Visa alla taggar i databasen
git tag -l "v2.*"

# Skapa hotfix-gren från specifik tagg
git checkout -b hotfix/crash-fix v2.4.1

Hierarki av Git Flow-grenar

Förståelse av grenhierarkin i Git Flow — grunden för korrekt organisation av samarbetsutveckling. Varje grenstyp har sin egen källa, syfte och sammanslagningsregler.

• Main (nivå 1) — rotgren, innehåller endast releaseversioner. Skapas vid initiering av databasen.
• Develop (nivå 2) — skapas från main i början av projektet. Innehåller integrationskod för alla funktioner.
• Feature (nivå 3) — skapas från develop. Isolerad utveckling av enskilda funktioner.
• Release (nivå 2) — skapas från develop. Förberedelse av en specifik release för publicering.
• Hotfix (nivå 2) — skapas från main. Akut korrigering av kritiska produktionsfel.

Viktig regel: feature slås aldrig samman direkt i main. feature → develop → release → main — korrekt sammanslagningskedja. Brott mot denna regel gör hela Git Flow-modellen meningslös.

Exempel på kommandon för att arbeta med main

Betrakta scenariot: teamet har slutfört förberedelserna av release v2.5.0. Release-grenen har kontrollerats och är redo för sammanslagning i main. Efter sammanslagning skapas taggen och releasen publiceras.

# Växla till main och uppdatera
git checkout main
git pull origin main

# Slå samman kontrollerad release-gren
git merge --no-ff release/2.5.0

# Skapa releasetagg
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Skicka main och taggen till servern
git push origin main --tags

Flaggan --no-ff (no fast-forward) garanterar skapandet av en merge-commit, även om sammanslagningen kunde ha utförts genom enkel förflyttning av pekaren. Detta bevarar informationen om att ändringarna kommer från release-grenen, vilket förenklar analysen av historiken.

Arbeta med hotfix via main

Om ett kritiskt fel upptäcks i produktion skiljer sig processen från en vanlig release. Hotfix skapas från main, och efter korrigering slås den samman både i main och i develop.

Om ett kritiskt fel upptäcks i produktion skiljer sig processen från en vanlig release. Hotfix skapas från main, och efter korrigering slås den samman både i main och i develop.

# Skapa hotfix-gren från main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Korrigera och committa
git add src/fix/
git commit -m "Fix crash on login screen"

# Slå samman hotfix tillbaka till 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

# Slå samman hotfix även till develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Ta bort hotfix-grenen
git branch -d hotfix/2.5.1-crash-fix