Main i Master Branch w Git: co to jest i do czego służy główna gałąź

Co to jest Main / Master Branch w Git

Main Branch (lub Master — w zależności od ustawień repozytorium) — to domyślna gałąź, która tworzy się przy inicjalizacji każdego repozytorium Git. Jest główną gałęzią projektu i zawiera kod gotowy do wdrożenia na produkcję.

W przeciwieństwie do develop, gdzie codziennie trwa intensywna praca nad nowymi funkcjami, main jest wizytówką projektu. Każda wersja kodu w main przeszła pełny cykl: rozwój w gałęzi feature, integracja w develop, przygotowanie wydania w gałęzi release i końcowe testowanie. Dopiero wtedy zmiany trafiają do main.

Kluczowa zasada: main zawsze powinna być stabilna. Jeśli w main zostanie znaleziony błąd, oznacza to pilny hotfix, który należy wydać poza kolejnością. Dlatego w profesjonalnych projektach main jest chroniona przed przypadkowymi zmianami za pomocą branch protection rules.

Według Git Book, main to nie specjalna gałąź o szczególnych właściwościach, ale zwykłe odniesienie do commitu, które zgodnie z konwencją uważa się za główne. Git nie rozróżnia main od żadnej innej gałęzi na poziomie systemu.

Przejście z master na main

Historycznie domyślna gałąź w Git nazywała się master. W czerwcu 2020 roku ruch Black Lives Matter zwrócił uwagę na terminy master i slave w branży IT. GitHub ogłosił przejście na termin main dla domyślnej gałęzi.

Od października 2020 roku wszystkie nowe repozytoria na GitHub są tworzone z gałęzią main. GitLab i Bitbucket również wprowadziły obsługę main jako domyślnej nazwy. Git 2.28 (lipiec 2020) dodał opcję init.defaultBranch do konfiguracji nazwy domyślnej gałęzi.

Technicznie zmiana nazwy istniejącej gałęzi z master na main to prosta operacja. Główna trudność polega na aktualizacji wszystkich odniesień w konfiguracjach CI/CD, dokumentacji i lokalnych repozytoriach programistów.

Aby zmienić nazwę gałęzi w istniejącym repozytorium, wykonaj:

# Lokalne zmiana nazwy master na main
git branch -m master main

# Aktualizacja zdalnego repozytorium
git push -u origin main

# Usunięcie starego master na serwerze
git push origin --delete master

# Aktualizacja HEAD na serwerze
# (przez interfejs webowy GitHub: Settings → Branches → Default branch)

Rola main w Git Flow i GitHub Flow

Git Flow i GitHub Flow różnie definiują rolę gałęzi main. Wybór modelu zależy od wielkości zespołu, częstotliwości wydań i wymagań dotyczących stabilności kodu.

Dla rozwoju aplikacji mobilnych standardem jest Git Flow, ponieważ publikacja aplikacji w App Store i Google Play ma stałe cykle wydawnicze. GitHub Flow jest bardziej odpowiedni dla projektów webowych z możliwością wdrażania kilka razy dziennie.

GitHub Flow — uproszczone podejście

W GitHub Flow nie ma gałęzi develop. Wszystkie gałęzie feature są tworzone bezpośrednio z main, a po zakończeniu są scalane z powrotem przez Pull Request. Każde scalenie w main automatycznie uruchamia wdrożenie na produkcję. Ten model wymaga wysokiej automatyzacji testowania i dyscypliny zespołu.

W GitHub Flow nie ma gałęzi develop. Wszystkie gałęzie feature są tworzone bezpośrednio z main, a po zakończeniu są scalane z powrotem przez Pull Request. Każde scalenie w main automatycznie uruchamia wdrożenie na produkcję. Ten model wymaga wysokiej automatyzacji testowania i dyscypliny zespołu.

Ochrona gałęzi main

Branch protection dla main — obowiązkowe ustawienie w każdym komercyjnym projekcie. Bez niego przypadkowy push może wysłać na produkcję niedokończony kod lub zepsuć działającą aplikację dla wszystkich użytkowników.

• Require pull request — bezpośredni push do main jest zabroniony. Wszystkie zmiany przez PR z recenzją.
• Require approvals — minimum 2 zatwierdzenia do scalenia w main (na wypadek błędu jednego recenzenta).
• Require status checks — wszystkie kontrole CI/CD muszą być pomyślne przed scaleniem.
• Require up-to-date — PR musi być oparty na najnowszym commicie main.
• Include administrators — ochrona działa nawet na właścicieli repozytorium.
• Require signed commits — wszystkie commity w main muszą być podpisane kluczem GPG.

Konfiguracja wszystkich sześciu zasad — standard dla projektów mobilnych z publicznością od 10 000+ użytkowników. Dla małych projektów wystarczą pierwsze trzy zasady.

Porównanie poziomów ochrony dla różnych typów projektów

Poziom ochrony main zależy od skali projektu. Startup może ograniczyć się do minimalnej ochrony, a aplikacja enterprise wymaga maksymalnych ograniczeń.

Wydania i tagi w main

Tagowanie (tagging) — praktyka tworzenia nazwanych odniesień do konkretnych commitów w main. Każdy tag odpowiada wersji aplikacji wydanej na produkcję. Pozwala to szybko przełączyć się na dowolne poprzednie wydanie do debugowania lub patcha.

Standard nazewnictwa tagów w rozwoju aplikacji mobilnych — SemVer (Semantic Versioning): v1.2.3, gdzie pierwszy numer to wersja główna (breaking changes), drugi — pomocnicza (nowe funkcje), trzeci — patch (poprawki).

Tag jest tworzony po scaleniu gałęzi release w main. Ten commit jest następnie budowany w CI/CD, podpisywany i wysyłany do sklepu z aplikacjami. Jeśli w tagu zostanie znaleziony błąd, tworzona jest gałąź hotfix od tego tagu.

# Tworzenie adnotowanego tagu wydania
git tag -a v2.4.1 -m "Release version 2.4.1"

# Wysyłanie tagu na serwer
git push origin v2.4.1

# Przegląd wszystkich tagów w repozytorium
git tag -l "v2.*"

# Tworzenie gałęzi hotfix od konkretnego tagu
git checkout -b hotfix/crash-fix v2.4.1

Hierarchia gałęzi Git Flow

Zrozumienie hierarchii gałęzi w Git Flow to podstawa prawidłowej organizacji wspólnego rozwoju. Każdy typ gałęzi ma swoje źródło, przeznaczenie i zasady scalania.

• Main (1. poziom) — gałąź główna, zawiera tylko wersje wydaniowe. Tworzona przy inicjalizacji repozytorium.
• Develop (2. poziom) — tworzona z main na początku projektu. Zawiera kod integracyjny wszystkich funkcji.
• Feature (3. poziom) — tworzone z develop. Izolowany rozwój poszczególnych funkcji.
• Release (2. poziom) — tworzona z develop. Przygotowanie konkretnego wydania do publikacji.
• Hotfix (2. poziom) — tworzona z main. Pilna naprawa krytycznych błędów produkcyjnych.

Ważna zasada: feature nigdy nie scala się bezpośrednio z main. feature → develop → release → main — to prawidłowy łańcuch scalania. Naruszenie tej zasady pozbawia sensu cały model Git Flow.

Przykłady poleceń do pracy z main

Rozpatrzmy scenariusz: zespół zakończył przygotowanie wydania v2.5.0. Gałąź release została sprawdzona i jest gotowa do scalenia z main. Po scaleniu tworzony jest tag i wydanie jest publikowane.

# Przełączenie na main i aktualizacja
git checkout main
git pull origin main

# Scalenie sprawdzonej gałęzi release
git merge --no-ff release/2.5.0

# Tworzenie tagu wydania
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Wysłanie main i tagu na serwer
git push origin main --tags

Flaga --no-ff (no fast-forward) gwarantuje utworzenie commitu scalenia, nawet jeśli scalenie można by wykonać przez proste przesunięcie wskaźnika. Zachowuje to informację o tym, że zmiany pochodzą z gałęzi release, co ułatwia analizę historii.

Praca z hotfix przez main

Jeśli na produkcji zostanie znaleziony krytyczny błąd, proces różni się od zwykłego wydania. Hotfix jest tworzony z main, a po naprawie scalany zarówno z main, jak i develop.

Jeśli na produkcji zostanie znaleziony krytyczny błąd, proces różni się od zwykłego wydania. Hotfix jest tworzony z main, a po naprawie scalany zarówno z main, jak i develop.

# Tworzenie gałęzi hotfix z main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Naprawa i commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Scalenie hotfix z powrotem do 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

# Scalenie hotfix również do develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Usunięcie gałęzi hotfix
git branch -d hotfix/2.5.1-crash-fix