Main és Master Branch a Gitben: mi ez és mire való a fő ág

Mi a Main / Master Branch a Gitben

Main Branch (vagy Master — a repozitórium beállításaitól függően) — az alapértelmezett ág, amely bármely Git repozitórium inicializálásakor létrejön. Ez a projekt fő ága, és tartalmazza az éles üzembe helyezésre kész kódot.

Ellentétben a develop-pal, ahol a mindennapi munka zajlik az új funkciókkal, a main a projekt kirakata. A main-ben lévő kód minden verziója teljes cikluson ment keresztül: fejlesztés a feature ágban, integráció a develop-ban, kiadás előkészítése a release ágban és végső tesztelés. Csak ezután kerülnek a változtatások a main-be.

Kulcsfontosságú elv: a main-nek mindig stabilnak kell lennie. Ha hibát fedeznek fel a main-ben, az sürgős hotfix-et jelent, amelyet soron kívül kell kiadni. Ezért a professzionális projektekben a main-t branch protection rules védi a véletlen módosításoktól.

A Git Book szerint a main nem egy különleges ág különleges tulajdonságokkal, hanem egy szokásos hivatkozás egy commit-ra, amelyet megegyezés szerint főnek tekintenek. A Git rendszerszinten nem tesz különbséget a main és bármely más ág között.

Átállás master-ről main-re

Történelmileg a Git alapértelmezett ágát master-nek hívták. 2020 júniusában a Black Lives Matter mozgalom felhívta a figyelmet a master és slave kifejezésekre az IT-iparban. A GitHub bejelentette az átállást a main kifejezésre az alapértelmezett ág számára.

2020 októbere óta az összes új repozitórium a GitHub-on a main ággal jön létre. A GitLab és a Bitbucket is bevezette a main támogatását alapértelmezett névként. A Git 2.28 (2020 július) hozzáadta az init.defaultBranch opciót az alapértelmezett ág nevének beállításához.

Technikailag egy meglévő ág átnevezése master-ről main-re egyszerű művelet. A fő kihívást az összes hivatkozás frissítése jelenti a CI/CD konfigurációkban, dokumentációkban és a fejlesztők lokális repozitóriumaiban.

Egy meglévő repozitóriumban az ág átnevezéséhez hajtsa végre:

# A master helyi átnevezése main-re
git branch -m master main

# A távoli repozitórium frissítése
git push -u origin main

# A régi master eltávolítása a szerverről
git push origin --delete master

# A HEAD frissítése a szerveren
# (a GitHub webes felületén: Settings → Branches → Default branch)

A main szerepe a Git Flow-ban és GitHub Flow-ban

Git Flow és GitHub Flow eltérően határozza meg a main ág szerepét. A modell kiválasztása a csapat méretétől, a kiadások gyakoriságától és a kódstabilitási követelményektől függ.

Mobilalkalmazás-fejlesztéshez a Git Flow a szabvány, mivel az alkalmazások közzététele az App Store-ban és a Google Play-ben rögzített kiadási ciklusokkal rendelkezik. A GitHub Flow jobban megfelel webes projektekhez, ahol lehetőség van napi többszöri telepítésre.

GitHub Flow — egyszerűsített megközelítés

A GitHub Flow-ban nincs develop ág. Minden feature ág közvetlenül a main-ből jön létre, és befejezés után Pull Request-en keresztül kerül visszaegyesítésre. Minden main-be történő egyesítés automatikusan elindítja az éles környezetbe telepítést. Ez a modell magas szintű tesztelési automatizálást és csapatfegyelmet igényel.

A GitHub Flow-ban nincs develop ág. Minden feature ág közvetlenül a main-ből jön létre, és befejezés után Pull Request-en keresztül kerül visszaegyesítésre. Minden main-be történő egyesítés automatikusan elindítja az éles környezetbe telepítést. Ez a modell magas szintű tesztelési automatizálást és csapatfegyelmet igényel.

A main ág védelme

Branch protection a main számára — kötelező beállítás minden kereskedelmi projektben. Enélkül egy véletlen push befejezetlen kódot küldhet éles környezetbe, vagy tönkreteheti a működő alkalmazást az összes felhasználó számára.

• Require pull request — a közvetlen push a main-be tilos. Minden módosítás PR-en keresztül, felülvizsgálattal.
• Require approvals — minimum 2 jóváhagyás a main-be egyesítéshez (egy felülvizsgáló hibája esetén).
• Require status checks — minden CI/CD ellenőrzésnek sikeresnek kell lennie az egyesítés előtt.
• Require up-to-date — a PR-nek a main legutóbbi commit-ján kell alapulnia.
• Include administrators — a védelem a repozitórium tulajdonosaira is vonatkozik.
• Require signed commits — minden main-be kerülő commit-ot GPG-kulccsal kell aláírni.

Mind a hat szabály beállítása — szabvány a 10 000+ felhasználót elérő mobil projektek számára. Kis projekteknél az első három szabály elegendő.

A védelmi szintek összehasonlítása különböző projekt típusokhoz

A main védelmének szintje a projekt méretétől függ. Egy startup megelégedhet minimális védelemmel, míg egy enterprise alkalmazás maximális korlátozásokat igényel.

Kiadások és tagek a main-ben

Tagelés (tagging) — névvel ellátott hivatkozások létrehozásának gyakorlata a main-ben lévő konkrét commit-okhoz. Minden tag megfelel a termelésbe kiadott alkalmazás egy verziójának. Ez lehetővé teszi a gyors váltást bármely korábbi kiadásra hibakeresés vagy javítás céljából.

A tagek elnevezésének szabványa mobilalkalmazás-fejlesztésben — SemVer (Szemantikus Verziókezelés): v1.2.3, ahol az első szám a főverzió (breaking changes), a második — a mellékverzió (új funkciók), a harmadik — a patch (javítások).

A tag a release ág main-be egyesítése után jön létre. Ezt a commit-ot ezután a CI/CD-ben lefordítják, aláírják és elküldik az alkalmazásboltba. Ha hibát fedeznek fel a tag-ben, hotfix ág jön létre abból a tag-ből.

# Annotált kiadási tag létrehozása
git tag -a v2.4.1 -m "Release version 2.4.1"

# Tag elküldése a szerverre
git push origin v2.4.1

# Összes tag megtekintése a repozitóriumban
git tag -l "v2.*"

# Hotfix ág létrehozása egy adott tag-ből
git checkout -b hotfix/crash-fix v2.4.1

A Git Flow ágak hierarchiája

A Git Flow ágak hierarchiájának megértése — az együttműködésen alapuló fejlesztés helyes megszervezésének alapja. Minden ágtípusnak megvan a maga forrása, célja és egyesítési szabályai.

• Main (1. szint) — gyökérág, csak kiadási verziókat tartalmaz. A repozitórium inicializálásakor jön létre.
• Develop (2. szint) — a projekt elején jön létre a main-ből. Tartalmazza az összes funkció integrációs kódját.
• Feature (3. szint) — a develop-ból jön létre. Az egyes funkciók elkülönített fejlesztése.
• Release (2. szint) — a develop-ból jön létre. Egy adott kiadás előkészítése a megjelenésre.
• Hotfix (2. szint) — a main-ből jön létre. Kritikus éles hibák sürgős javítása.

Fontos szabály: a feature soha nem egyesül közvetlenül a main-be. feature → develop → release → main — a helyes egyesítési lánc. Ennek a szabálynak a megsértése értelmetlenné teszi a teljes Git Flow modellt.

Példák parancsokra a main-nel való munkához

Tekintsük a forgatókönyvet: a csapat befejezte a v2.5.0 kiadás előkészítését. A release ág ellenőrzésre került és készen áll a main-be egyesítésre. Az egyesítés után létrejön a tag, és a kiadás publikálásra kerül.

# Váltás main-re és frissítés
git checkout main
git pull origin main

# Ellenőrzött release ág egyesítése
git merge --no-ff release/2.5.0

# Kiadási tag létrehozása
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Main és tag elküldése a szerverre
git push origin main --tags

A --no-ff (no fast-forward) zászló garantálja az egyesítési commit létrehozását, még akkor is, ha az egyesítés a mutató egyszerű mozgatásával is végrehajtható lenne. Ez megőrzi azt az információt, hogy a változtatások a release ágból származnak, ami leegyszerűsíti az előzmények elemzését.

Munka hotfix-szel a main-en keresztül

Ha kritikus hibát fedeznek fel éles környezetben, a folyamat eltér a szokásos kiadástól. A hotfix a main-ből jön létre, és a javítás után mind a main-be, mind a develop-ba egyesül.

Ha kritikus hibát fedeznek fel éles környezetben, a folyamat eltér a szokásos kiadástól. A hotfix a main-ből jön létre, és a javítás után mind a main-be, mind a develop-ba egyesül.

# Hotfix ág létrehozása main-ből
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Javítás és commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Hotfix visszaegyesítése main-be
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 egyesítése develop-ba is
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Hotfix ág törlése
git branch -d hotfix/2.5.1-crash-fix