Main și Master Branch în Git: ce este și de ce este necesară ramura principală

Ce este Main / Master Branch în Git

Main Branch (sau Master — în funcție de setările depozitului) — este ramura implicită care se creează la inițializarea oricărui depozit Git. Este ramura principală a proiectului și conține codul gata de implementare în producție.

Spre deosebire de develop, unde are loc munca zilnică cu funcții noi, main este vitrina proiectului. Fiecare versiune de cod din main a parcurs un ciclu complet: dezvoltare în ramura feature, integrare în develop, pregătirea lansării în ramura release și testare finală. Abia după aceea modificările ajung în main.

Principiu cheie: main trebuie să fie întotdeauna stabilă. Dacă se descoperă o eroare în main, aceasta înseamnă un hotfix urgent care trebuie lansat în afara programului. De aceea, în proiectele profesionale, main este protejată de modificări accidentale prin branch protection rules.

Potrivit Git Book, main nu este o ramură specială cu proprietăți deosebite, ci o referință obișnuită la un commit care, prin convenție, este considerată principală. Git nu face distincție între main și orice altă ramură la nivel de sistem.

Tranziția de la master la main

Istoric, ramura implicită în Git se numea master. În iunie 2020, mișcarea Black Lives Matter a atras atenția asupra termenilor master și slave în industria IT. GitHub a anunțat tranziția la termenul main pentru ramura implicită.

Începând cu octombrie 2020, toate depozitele noi pe GitHub sunt create cu ramura main. GitLab și Bitbucket au implementat, de asemenea, suportul pentru main ca nume implicit. Git 2.28 (iulie 2020) a adăugat opțiunea init.defaultBranch pentru configurarea numelui ramurii implicite.

Din punct de vedere tehnic, redenumirea unei ramuri existente din master în main este o operațiune simplă. Dificultatea principală constă în actualizarea tuturor referințelor din configurațiile CI/CD, documentație și depozitele locale ale dezvoltatorilor.

Pentru a redenumi ramura într-un depozit existent, executați:

# Redenumirea locală a master în main
git branch -m master main

# Actualizarea depozitului la distanță
git push -u origin main

# Ștergerea vechiului master pe server
git push origin --delete master

# Actualizarea HEAD pe server
# (prin interfața web GitHub: Settings → Branches → Default branch)

Rolul main în Git Flow și GitHub Flow

Git Flow și GitHub Flow definesc diferit rolul ramurii main. Alegerea modelului depinde de mărimea echipei, frecvența lansărilor și cerințele de stabilitate a codului.

Pentru dezvoltarea de aplicații mobile, standardul este Git Flow, deoarece publicarea aplicației în App Store și Google Play are cicluri de lansare fixe. GitHub Flow este mai potrivit pentru proiecte web cu posibilitatea de implementare de mai multe ori pe zi.

GitHub Flow — abordare simplificată

În GitHub Flow nu există ramura develop. Toate ramurile feature sunt create direct din main, iar după finalizare sunt reunite înapoi prin Pull Request. Fiecare reunire în main declanșează automat implementarea în producție. Acest model necesită automatizare avansată a testării și disciplină de echipă.

În GitHub Flow nu există ramura develop. Toate ramurile feature sunt create direct din main, iar după finalizare sunt reunite înapoi prin Pull Request. Fiecare reunire în main declanșează automat implementarea în producție. Acest model necesită automatizare avansată a testării și disciplină de echipă.

Protejarea ramurii main

Branch protection pentru main — o configurație obligatorie în orice proiect comercial. Fără ea, un push accidental poate trimite în producție cod neterminat sau poate strica aplicația funcțională pentru toți utilizatorii.

• Require pull request — push-ul direct în main este interzis. Toate modificările prin PR cu revizuire.
• Require approvals — minimum 2 aprobări pentru reunirea în main (în caz de eroare a unui recenzent).
• Require status checks — toate verificările CI/CD trebuie să fie reușite înainte de reunire.
• Require up-to-date — PR trebuie să se bazeze pe cel mai recent commit din main.
• Include administrators — protecția se aplică chiar și proprietarilor depozitului.
• Require signed commits — toate commit-urile în main trebuie să fie semnate cu cheie GPG.

Configurarea tuturor celor șase reguli — standard pentru proiectele mobile cu audiență de 10.000+ utilizatori. Pentru proiectele mici, primele trei reguli sunt suficiente.

Compararea nivelurilor de protecție pentru diferite tipuri de proiecte

Nivelul de protecție a main depinde de scara proiectului. Un startup se poate descurca cu protecție minimă, în timp ce o aplicație enterprise necesită restricții maxime.

Lansări și etichete în main

Etichetarea (tagging) — practica creării de referințe denumite către commit-uri specifice din main. Fiecare etichetă corespunde unei versiuni de aplicație lansate în producție. Aceasta permite comutarea rapidă la orice lansare anterioară pentru depanare sau patch.

Standardul de denumire a etichetelor în dezvoltarea de aplicații mobile — SemVer (Semantic Versioning): v1.2.3, unde primul număr este versiunea majoră (breaking changes), al doilea — minoră (funcții noi), al treilea — patch (corecții).

Eticheta se creează după reunirea ramurii release în main. Acest commit este apoi construit în CI/CD, semnat și trimis în magazinul de aplicații. Dacă se descoperă o eroare în etichetă, se creează o ramură hotfix din acea etichetă.

# Crearea unei etichete de lansare adnotate
git tag -a v2.4.1 -m "Release version 2.4.1"

# Trimiterea etichetei pe server
git push origin v2.4.1

# Vizualizarea tuturor etichetelor din depozit
git tag -l "v2.*"

# Crearea unei ramuri hotfix dintr-o etichetă specifică
git checkout -b hotfix/crash-fix v2.4.1

Ierarhia ramurilor Git Flow

Înțelegerea ierarhiei ramurilor în Git Flow — fundamentul organizării corecte a dezvoltării colaborative. Fiecare tip de ramură are sursa, scopul și regulile de reunire proprii.

• Main (nivelul 1) — ramura rădăcină, conține doar versiuni de lansare. Se creează la inițializarea depozitului.
• Develop (nivelul 2) — se creează din main la începutul proiectului. Conține codul de integrare al tuturor funcțiilor.
• Feature (nivelul 3) — se creează din develop. Dezvoltare izolată a funcțiilor individuale.
• Release (nivelul 2) — se creează din develop. Pregătirea unei anumite lansări pentru publicare.
• Hotfix (nivelul 2) — se creează din main. Corectarea urgentă a erorilor critice de producție.

Regulă importantă: feature nu se reunește niciodată direct în main. feature → develop → release → main — lanțul corect de reunire. Încălcarea acestei reguli face ca întregul model Git Flow să-și piardă sensul.

Exemple de comenzi pentru lucrul cu main

Luați în considerare scenariul: echipa a finalizat pregătirea lansării v2.5.0. Ramura release a fost verificată și este gata pentru reunirea în main. După reunire, se creează eticheta și lansarea este publicată.

# Comutarea la main și actualizarea
git checkout main
git pull origin main

# Reunirea ramurii release verificate
git merge --no-ff release/2.5.0

# Crearea etichetei de lansare
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Trimiterea main și a etichetei pe server
git push origin main --tags

Fanionul --no-ff (no fast-forward) garantează crearea unui commit de reunire, chiar dacă reunirea ar fi putut fi realizată prin simpla mutare a indicatorului. Aceasta păstrează informația că modificările provin din ramura release, ceea ce simplifică analiza istoricului.

Lucrul cu hotfix prin main

Dacă se descoperă o eroare critică în producție, procesul diferă de lansarea obișnuită. Hotfix-ul se creează din main, iar după corectare se reunește atât în main, cât și în develop.

Dacă se descoperă o eroare critică în producție, procesul diferă de lansarea obișnuită. Hotfix-ul se creează din main, iar după corectare se reunește atât în main, cât și în develop.

# Crearea ramurii hotfix din main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

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

# Reunirea hotfix înapoi în 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

# Reunirea hotfix, de asemenea, în develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Ștergerea ramurii hotfix
git branch -d hotfix/2.5.1-crash-fix