Main και Master Branch στο Git: τι είναι και γιατί χρειάζεται ο κύριος κλάδος

Τι είναι το Main / Master Branch στο Git

Main Branch (ή Master — ανάλογα με τις ρυθμίσεις του αποθετηρίου) — είναι ο προκαθορισμένος κλάδος που δημιουργείται κατά την αρχικοποίηση οποιουδήποτε αποθετηρίου Git. Είναι ο κύριος κλάδος του έργου και περιέχει κώδικα έτοιμο για ανάπτυξη στην παραγωγή.

Σε αντίθεση με το develop, όπου γίνεται η καθημερινή εργασία με νέες λειτουργίες, το main είναι η βιτρίνα του έργου. Κάθε έκδοση κώδικα στο main έχει περάσει από έναν πλήρη κύκλο: ανάπτυξη στον κλάδο feature, ενσωμάτωση στο develop, προετοιμασία έκδοσης στον κλάδο release και τελική δοκιμή. Μόνο μετά από αυτό οι αλλαγές εισέρχονται στο main.

Βασική αρχή: το main πρέπει να είναι πάντα σταθερό. Εάν ανακαλυφθεί σφάλμα στο main, αυτό σημαίνει επείγον hotfix που πρέπει να κυκλοφορήσει εκτός προγράμματος. Γι' αυτό σε επαγγελματικά έργα, το main προστατεύεται από τυχαίες αλλαγές μέσω branch protection rules.

Σύμφωνα με το Git Book, το main δεν είναι ένας ειδικός κλάδος με ιδιαίτερες ιδιότητες, αλλά μια συνηθισμένη αναφορά σε ένα commit που κατά σύμβαση θεωρείται κύριος. Το Git δεν κάνει διάκριση μεταξύ main και οποιουδήποτε άλλου κλάδου σε επίπεδο συστήματος.

Μετάβαση από master σε main

Ιστορικά, ο προκαθορισμένος κλάδος στο Git ονομαζόταν master. Τον Ιούνιο του 2020, το κίνημα Black Lives Matter επέστησε την προσοχή στους όρους master και slave στη βιομηχανία IT. Το GitHub ανακοίνωσε τη μετάβαση στον όρο main για τον προκαθορισμένο κλάδο.

Από τον Οκτώβριο 2020, όλα τα νέα αποθετήρια στο GitHub δημιουργούνται με τον κλάδο main. Οι GitLab και Bitbucket εφάρμοσαν επίσης υποστήριξη για το main ως προκαθορισμένο όνομα. Το Git 2.28 (Ιούλιος 2020) πρόσθεσε την επιλογή init.defaultBranch για τη διαμόρφωση του ονόματος του προκαθορισμένου κλάδου.

Τεχνικά, η μετονομασία ενός υπάρχοντος κλάδου από master σε main είναι μια απλή λειτουργία. Η κύρια πρόκληση είναι η ενημέρωση όλων των αναφορών σε διαμορφώσεις CI/CD, τεκμηρίωση και τοπικά αποθετήρια προγραμματιστών.

Για να μετονομάσετε έναν κλάδο σε ένα υπάρχον αποθετήριο, εκτελέστε:

# Τοπική μετονομασία του master σε main
git branch -m master main

# Ενημέρωση του απομακρυσμένου αποθετηρίου
git push -u origin main

# Διαγραφή του παλιού master στον διακομιστή
git push origin --delete master

# Ενημέρωση του HEAD στον διακομιστή
# (μέσω της διαδικτυακής διεπαφής GitHub: Settings → Branches → Default branch)

Ρόλος του main στο Git Flow και GitHub Flow

Git Flow και GitHub Flow ορίζουν διαφορετικά τον ρόλο του κλάδου main. Η επιλογή μοντέλου εξαρτάται από το μέγεθος της ομάδας, τη συχνότητα εκδόσεων και τις απαιτήσεις σταθερότητας κώδικα.

Για ανάπτυξη εφαρμογών κινητών, το πρότυπο είναι Git Flow, καθώς η δημοσίευση εφαρμογών στο App Store και το Google Play έχει σταθερούς κύκλους έκδοσης. Το GitHub Flow είναι πιο κατάλληλο για έργα web με δυνατότητα ανάπτυξης πολλές φορές την ημέρα.

GitHub Flow — απλοποιημένη προσέγγιση

Στο GitHub Flow δεν υπάρχει κλάδος develop. Όλοι οι κλάδοι feature δημιουργούνται απευθείας από το main, και μετά την ολοκλήρωση συγχωνεύονται πίσω μέσω Pull Request. Κάθε συγχώνευση στο main ενεργοποιεί αυτόματα ανάπτυξη στην παραγωγή. Αυτό το μοντέλο απαιτεί υψηλή αυτοματοποίηση δοκιμών και πειθαρχία ομάδας.

Στο GitHub Flow δεν υπάρχει κλάδος develop. Όλοι οι κλάδοι feature δημιουργούνται απευθείας από το main, και μετά την ολοκλήρωση συγχωνεύονται πίσω μέσω Pull Request. Κάθε συγχώνευση στο main ενεργοποιεί αυτόματα ανάπτυξη στην παραγωγή. Αυτό το μοντέλο απαιτεί υψηλή αυτοματοποίηση δοκιμών και πειθαρχία ομάδας.

Προστασία του main κλάδου

Branch protection για το main — υποχρεωτική ρύθμιση σε κάθε εμπορικό έργο. Χωρίς αυτήν, ένα τυχαίο push μπορεί να στείλει ημιτελή κώδικα στην παραγωγή ή να καταστρέψει μια λειτουργική εφαρμογή για όλους τους χρήστες.

• Require pull request — το άμεσο push στο main απαγορεύεται. Όλες οι αλλαγές μέσω PR με αναθεώρηση.
• Require approvals — τουλάχιστον 2 εγκρίσεις για συγχώνευση στο main (σε περίπτωση σφάλματος ενός αναθεωρητή).
• Require status checks — όλοι οι έλεγχοι CI/CD πρέπει να είναι επιτυχείς πριν από τη συγχώνευση.
• Require up-to-date — το PR πρέπει να βασίζεται στο πιο πρόσφατο commit του main.
• Include administrators — η προστασία ισχύει ακόμη και για τους ιδιοκτήτες του αποθετηρίου.
• Require signed commits — όλα τα commits στο main πρέπει να υπογράφονται με κλειδί GPG.

Η ρύθμιση και των έξι κανόνων — πρότυπο για έργα κινητών με κοινό 10.000+ χρηστών. Για μικρά έργα, οι πρώτοι τρεις κανόνες είναι επαρκείς.

Σύγκριση επιπέδων προστασίας για διαφορετικούς τύπους έργων

Το επίπεδο προστασίας του main εξαρτάται από την κλίμακα του έργου. Μια startup μπορεί να λειτουργήσει με ελάχιστη προστασία, ενώ μια εφαρμογή enterprise απαιτεί μέγιστους περιορισμούς.

Εκδόσεις και ετικέτες στο main

Επισήμανση (tagging) — η πρακτική δημιουργίας ονομασμένων αναφορών σε συγκεκριμένα commits στο main. Κάθε ετικέτα αντιστοιχεί σε μια έκδοση εφαρμογής που κυκλοφόρησε στην παραγωγή. Αυτό επιτρέπει γρήγορη εναλλαγή σε οποιαδήποτε προηγούμενη έκδοση για εντοπισμό σφαλμάτων ή επιδιόρθωση.

Το πρότυπο ονομασίας ετικετών στην ανάπτυξη εφαρμογών κινητών — SemVer (Semantic Versioning): v1.2.3, όπου ο πρώτος αριθμός είναι η κύρια έκδοση (breaking changes), ο δεύτερος — δευτερεύουσα (νέες λειτουργίες), ο τρίτος — patch (διορθώσεις).

Η ετικέτα δημιουργείται μετά τη συγχώνευση του κλάδου release στο main. Αυτό το commit στη συνέχεια χτίζεται στο CI/CD, υπογράφεται και αποστέλλεται στο κατάστημα εφαρμογών. Εάν ανακαλυφθεί σφάλμα στην ετικέτα, δημιουργείται ένας κλάδος hotfix από αυτήν την ετικέτα.

# Δημιουργία σχολιασμένης ετικέτας έκδοσης
git tag -a v2.4.1 -m "Release version 2.4.1"

# Αποστολή της ετικέτας στον διακομιστή
git push origin v2.4.1

# Προβολή όλων των ετικετών στο αποθετήριο
git tag -l "v2.*"

# Δημιουργία hotfix κλάδου από συγκεκριμένη ετικέτα
git checkout -b hotfix/crash-fix v2.4.1

Ιεραρχία κλάδων Git Flow

Η κατανόηση της ιεραρχίας κλάδων στο Git Flow — το θεμέλιο για τη σωστή οργάνωση της συνεργατικής ανάπτυξης. Κάθε τύπος κλάδου έχει τη δική του πηγή, σκοπό και κανόνες συγχώνευσης.

• Main (Επίπεδο 1) — ριζικός κλάδος, περιέχει μόνο εκδόσεις. Δημιουργείται κατά την αρχικοποίηση του αποθετηρίου.
• Develop (Επίπεδο 2) — δημιουργείται από το main κατά την έναρξη του έργου. Περιέχει τον κώδικα ενσωμάτωσης όλων των λειτουργιών.
• Feature (Επίπεδο 3) — δημιουργούνται από το develop. Απομονωμένη ανάπτυξη μεμονωμένων λειτουργιών.
• Release (Επίπεδο 2) — δημιουργείται από το develop. Προετοιμασία συγκεκριμένης έκδοσης για κυκλοφορία.
• Hotfix (Επίπεδο 2) — δημιουργείται από το main. Επείγουσα διόρθωση κρίσιμων σφαλμάτων παραγωγής.

Σημαντικός κανόνας: το feature δεν συγχωνεύεται ποτέ απευθείας στο main. feature → develop → release → main — η σωστή αλυσίδα συγχώνευσης. Η παραβίαση αυτού του κανόνα στερεί νοήματος από ολόκληρο το μοντέλο Git Flow.

Παραδείγματα εντολών για εργασία με main

Εξετάστε το σενάριο: η ομάδα ολοκλήρωσε την προετοιμασία της έκδοσης v2.5.0. Ο κλάδος release ελέγχθηκε και είναι έτοιμος για συγχώνευση στο main. Μετά τη συγχώνευση, δημιουργείται η ετικέτα και η έκδοση δημοσιεύεται.

# Μετάβαση σε main και ενημέρωση
git checkout main
git pull origin main

# Συγχώνευση ελεγμένου release κλάδου
git merge --no-ff release/2.5.0

# Δημιουργία ετικέτας έκδοσης
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Αποστολή main και ετικέτας στον διακομιστή
git push origin main --tags

Η σημαία --no-ff (no fast-forward) εγγυάται τη δημιουργία ενός commit συγχώνευσης, ακόμη κι αν η συγχώνευση θα μπορούσε να γίνει με απλή μετακίνηση του δείκτη. Αυτό διατηρεί την πληροφορία ότι οι αλλαγές προέρχονται από τον κλάδο release, γεγονός που απλοποιεί την ανάλυση ιστορικού.

Εργασία με hotfix μέσω main

Εάν ανακαλυφθεί κρίσιμο σφάλμα στην παραγωγή, η διαδικασία διαφέρει από τη συνήθη έκδοση. Το hotfix δημιουργείται από το main, και μετά τη διόρθωση συγχωνεύεται τόσο στο main όσο και στο develop.

Εάν ανακαλυφθεί κρίσιμο σφάλμα στην παραγωγή, η διαδικασία διαφέρει από τη συνήθη έκδοση. Το hotfix δημιουργείται από το main, και μετά τη διόρθωση συγχωνεύεται τόσο στο main όσο και στο develop.

# Δημιουργία hotfix κλάδου από main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Διόρθωση και commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Συγχώνευση hotfix πίσω στο 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 επίσης στο develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Διαγραφή hotfix κλάδου
git branch -d hotfix/2.5.1-crash-fix