Git Flow: τι είναι, μοντέλο διακλάδωσης και χρήση σε έργα

Τι είναι το Git Flow;

Git Flow — είναι ένα μοντέλο διακλάδωσης Git που καθορίζει μια αυστηρή δομή κλαδιών και κανόνες συγχώνευσης για τη διαχείριση της ανάπτυξης, των εκδόσεων και των διορθώσεων. Ο Vincent Driessen δημοσίευσε το άρθρο 'A successful Git branching model' τον Ιανουάριο του 2010 και από τότε το Git Flow έγινε το de facto πρότυπο στην εταιρική ανάπτυξη Java και .NET. Η βασική ιδέα — ο διαχωρισμός του κώδικα σε πέντε τύπους κλαδιών με διαφορετικά επίπεδα σταθερότητας.

Σύμφωνα με το Atlassian Git Tutorials, 2024, το Git Flow βασίζεται σε δύο μόνιμα κλαδιά: main (πρώην master) και develop. Όλα τα άλλα κλαδιά είναι προσωρινά: feature, release, hotfix. Κάθε τύπος κλαδιού έχει σαφώς καθορισμένο κύκλο ζωής και κανόνες συγχώνευσης. Στην ανάπτυξη εφαρμογών για κινητά, το Git Flow εφαρμόζεται σε έργα με τακτικούς κύκλους έκδοσης (2–4 εβδομάδες) και υποστήριξη πολλαπλών εκδόσεων.

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

Vincent Driessen και η ιστορία του Git Flow

Το 2010, ο Vincent Driessen δημοσίευσε την ανάρτηση 'A successful Git branching model', η οποία έγινε μία από τις πιο αναφερόμενες στην ιστορία του Git. Το μοντέλο δημιουργήθηκε για ένα έργο με σταθερές εκδόσεις και παράλληλη υποστήριξη εκδόσεων. Το 2020, ο Driessen παραδέχτηκε ότι το Git Flow είναι ξεπερασμένο για τις σύγχρονες πρακτικές CI/CD, αλλά το μοντέλο παραμένει σχετικό για έργα με μακρύ κύκλο έκδοσης και την ανάγκη υποστήριξης παλαιών εκδόσεων.

# Αρχικοποίηση Git Flow
git flow init

# Δημιουργία feature κλαδιού
git flow feature start "add-auth"

# Ολοκλήρωση feature κλαδιού (συγχώνευση στο develop)
git flow feature finish "add-auth"

# Δημιουργία release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Κλαδί Main: κώδικας έκδοσης και επισήμανση

Main (πρώην master) — το κύριο κλαδί που περιέχει μόνο τον κώδικα έκδοσης έτοιμο για ανάπτυξη. Κάθε commit στο main πρέπει να αντιστοιχεί σε μια συγκεκριμένη έκδοση του προϊόντος, σημασμένη με ετικέτα (tag) σε μορφή σημασιολογικής έκδοσης, για παράδειγμα v1.0.0, v1.1.0. Καμία άμεση ανάπτυξη στο main δεν πραγματοποιείται — οι αλλαγές φτάνουν εδώ μόνο μέσω των κλαδιών release ή hotfix.

Σύμφωνα με το semver.org, 2024, οι ετικέτες στο main χρησιμοποιούν τη μορφή MAJOR.MINOR.PATCH. Το MAJOR αυξάνεται για ασύμβατες αλλαγές API, το MINOR — για προσθήκη λειτουργικότητας με συμβατότητα προς τα πίσω, το PATCH — για διορθώσεις σφαλμάτων. Στο Git Flow, κάθε finish release δημιουργεί αυτόματα ένα commit στο main με ετικέτα έκδοσης.

Main — το μοναδικό κλαδί που αναπτύσσεται στην παραγωγή. Για έργα κινητών, αυτό σημαίνει ότι με push στο main, ξεκινά το pipeline δημιουργίας App Bundle ή IPA και δημοσίευσης στο Google Play / App Store. Στις ρυθμίσεις CI/CD του GitLab, το main προστατεύεται από force-push και διαγραφή.

Σημασιολογική έκδοση και ετικέτες

Κάθε commit στο main συνοδεύεται από μια ετικέτα σε μορφή SemVer: vMAJOR.MINOR.PATCH. MAJOR — για ασύμβατες αλλαγές API, MINOR — για νέα λειτουργικότητα με συμβατότητα προς τα πίσω, PATCH — για διορθώσεις σφαλμάτων. Παράδειγμα: v2.1.0 σημαίνει δεύτερη μεγάλη έκδοση με νέες λειτουργίες και χωρίς διορθώσεις σφαλμάτων. Στο Git Flow, οι ετικέτες δημιουργούνται αυτόματα κατά την ολοκλήρωση release ή hotfix μέσω της εντολής git flow release finish.

Κλαδί Develop: γραμμή ενοποίησης ανάπτυξης

Develop — το δεύτερο μόνιμο κλαδί του Git Flow, που προορίζεται για την ενοποίηση όλων των ολοκληρωμένων λειτουργιών. Οι προγραμματιστές συγχωνεύουν τα feature κλαδιά στο develop αφού περάσουν από αναθεώρηση κώδικα και ελέγχους CI/CD. Το Develop περιέχει την πιο πρόσφατη σταθερή έκδοση κώδικα που περιλαμβάνει όλες τις υλοποιημένες λειτουργίες του τρέχοντος sprint.

Σύμφωνα με το DataSift Git Flow Guide, 2024, το develop μπορεί να είναι προσωρινά ασταθές λόγω ημιτελών ενοποιήσεων. Για την αποφυγή προβλημάτων, οι ομάδες εφαρμόζουν Continuous Integration (CI): κάθε λειτουργία πριν από τη συγχώνευση στο develop περνά από μια πλήρη σειρά δοκιμών. Εάν το CI αποτύχει — ο προγραμματιστής διορθώνει τον κώδικα μέχρι την επόμενη συγχώνευση. Το Develop είναι πάντα συνδεδεμένο με την τρέχουσα έκδοση του main: αμέσως μετά την έκδοση, το develop συγχρονίζεται με το main μέσω συγχώνευσης.

Feature κλαδιά: ανάπτυξη νέας λειτουργικότητας

Feature κλαδιά — προσωρινά κλαδιά για την ανάπτυξη μεμονωμένων λειτουργιών, διορθώσεων σφαλμάτων ή πειραμάτων. Κάθε feature κλαδί δημιουργείται από το develop και μετά την ολοκλήρωση συγχωνεύεται πίσω στο develop. Το όνομα του feature κλαδιού συνήθως περιέχει τον αριθμό εργασίας ή μια σύντομη περιγραφή: feature/APP-123-add-oauth, feature/redesign-profile. Στο Git Flow, τα feature κλαδιά μπορούν να υπάρχουν για απεριόριστο χρόνο.

Σύμφωνα με το Pro Git Book, 2024, τα feature κλαδιά είναι ένα απομονωμένο περιβάλλον ανάπτυξης: οι αλλαγές σε ένα κλαδί δεν επηρεάζουν τα άλλα μέχρι τη στιγμή της συγχώνευσης. Σε έργα κινητών, τα feature κλαδιά συγχρονίζονται με το develop μέσω rebase ή merge για να αποφευχθούν μεγάλες συγκρούσεις κατά την ολοκλήρωση. Συνιστάται το rebase του feature κλαδιού στο develop πριν από τη δημιουργία MR.

# Μη αυτόματη δημιουργία feature κλαδιού (χωρίς git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Δημιουργία MR στο GitLab μέσω CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release κλαδιά: προετοιμασία έκδοσης

Release κλαδιά — προσωρινά κλαδιά που δημιουργούνται από το develop για την προετοιμασία έκδοσης. Όταν το develop περιέχει ένα επαρκές σύνολο λειτουργιών για μια νέα έκδοση, η ομάδα δημιουργεί το κλαδί release/X.Y.Z (για παράδειγμα, release/2.1.0). Σε αυτό το κλαδί γίνονται μόνο τελικές αλλαγές: αύξηση έκδοσης, ενημέρωση τοπικοποίησης, τελικές δοκιμές, διόρθωση κρίσιμων σφαλμάτων.

Σύμφωνα με το Atlassian Git Tutorials, 2024, το release κλαδί λύνει ένα βασικό πρόβλημα: την απομόνωση των τελικών αλλαγών από την παράλληλη ανάπτυξη. Ενώ το release προετοιμάζεται για κυκλοφορία, στο develop συνεχίζονται να συγχωνεύονται νέες λειτουργίες για την επόμενη έκδοση. Μετά την ολοκλήρωση, το release κλαδί συγχωνεύεται στο main (με ετικέτα) και στο develop (για συγχρονισμό της αύξησης έκδοσης).

Hotfix κλαδιά: επείγουσες διορθώσεις στην παραγωγή

Hotfix κλαδιά — προσωρινά κλαδιά για επείγουσα διόρθωση κρίσιμων σφαλμάτων στην παραγωγή. Ο μοναδικός τύπος κλαδιού Git Flow που δημιουργείται από το main, όχι από το develop. Μορφή ονόματος: hotfix/X.Y.Z+1 (για παράδειγμα, hotfix/2.1.1). Μετά την ολοκλήρωση, το hotfix κλαδί συγχωνεύεται ταυτόχρονα στο main (ως νέα έκδοση επιδιόρθωσης) και στο develop (για να μην χαθεί η διόρθωση στις επόμενες εκδόσεις).

Σύμφωνα με το DataSift Git Flow Guide, 2024, τα hotfix κλαδιά πρέπει να είναι όσο το δυνατόν πιο σύντομα — μόνο διόρθωση και δοκιμή. Το hotfix δεν πρέπει να περιλαμβάνει νέες λειτουργίες ή αναδιάρθρωση. Στην ανάπτυξη εφαρμογών για κινητά, το hotfix χρησιμοποιείται για τη διόρθωση κρίσιμων καταρρεύσεων (ποσοστό crash > 0,1%), τρωτών σημείων ασφαλείας ή σφαλμάτων αποκλεισμού στο App Store.

Πλεονεκτήματα και μειονεκτήματα του Git Flow για ανάπτυξη σε κινητά

Git Flow παρέχει μια σαφή δομή που είναι ιδιαίτερα χρήσιμη για μεγάλες ομάδες και έργα με τακτικές εκδόσεις. Πλεονεκτήματα: απομόνωση ημιτελών λειτουργιών σε feature κλαδιά, δυνατότητα προετοιμασίας έκδοσης χωρίς αποκλεισμό της ανάπτυξης, υποστήριξη πολλαπλών εκδόσεων μέσω hotfix. Μειονεκτήματα: πολυπλοκότητα για αρχάριους, ανάγκη τακτικού rebase των feature κλαδιών, συγκρούσεις σε μακρόβια κλαδιά.

Σύμφωνα με το Martin Fowler, 2024, το κύριο μειονέκτημα του Git Flow — τα μακρόβια feature κλαδιά. Εάν μια λειτουργία αναπτύσσεται για 2+ εβδομάδες χωρίς συγχρονισμό με το develop, η σύγκρουση κατά τη συγχώνευση γίνεται σημαντική. Για έργα κινητών, συνιστάται ο καθημερινός συγχρονισμός του feature κλαδιού μέσω rebase στο develop.

Git Flow δεν συνιστάται για έργα με Continuous Deployment (κάθε commit στο main → στην παραγωγή). Για τέτοια έργα, το GitHub Flow ή το Trunk-Based Development παρέχουν ένα απλούστερο και ταχύτερο μοντέλο. Αλλά για έργα με κύκλους έκδοσης και υποστήριξη παλαιών εκδόσεων, το Git Flow παραμένει η βέλτιστη επιλογή.

Πότε το Git Flow είναι επιβλαβές για την ομάδα

Το Git Flow γίνεται πρόβλημα σε τρεις περιπτώσεις: ομάδα μικρότερη από 5 άτομα (υπερβολική πολυπλοκότητα), Continuous Deployment (καθυστέρηση παράδοσης), έλλειψη πειθαρχίας rebase (μακρόβια feature κλαδιά δημιουργούν συγκρούσεις συγχώνευσης). Εάν η ομάδα ξοδεύει περισσότερο από το 20% του χρόνου στη συγχώνευση κλαδιών και την επίλυση συγκρούσεων — το Git Flow δεν είναι κατάλληλο για αυτήν την ομάδα, ακόμη και σε μεγάλο μέγεθος.

Εναλλακτικές του Git Flow: GitHub Flow και Trunk-Based Development

Εναλλακτικές του Git Flow προσφέρουν μια απλούστερη διαδικασία για ομάδες που εφαρμόζουν CI/CD. GitHub Flow χρησιμοποιεί μόνο ένα μόνιμο κλαδί (main) και feature κλαδιά. Κάθε λειτουργία δημιουργείται από το main, μετά από αναθεώρηση και CI συγχωνεύεται πίσω στο main και αναπτύσσεται άμεσα. Το GitHub Flow είναι απλούστερο, αλλά δεν υποστηρίζει απομόνωση ημιτελών λειτουργιών και παράλληλη προετοιμασία έκδοσης.

Σύμφωνα με το GitHub Docs, 2024, το Trunk-Based Development (TBD) πηγαίνει ακόμα παραπέρα: όλοι οι προγραμματιστές εργάζονται σε ένα κλαδί (trunk), χρησιμοποιώντας βραχύβια feature κλαδιά 1–2 ημερών. Τα feature toggles (διακόπτες λειτουργιών) ελέγχουν την ορατότητα του ημιτελούς κώδικα. Το TBD απαιτεί υψηλή πειθαρχία CI/CD και αυτοματοποίηση δοκιμών.

• GitHub Flow — ένα main + feature κλαδιά, ιδανικό για CI/CD και μικρές ομάδες
• GitLab Flow — αναπτύσσει το Git Flow με κλαδιά περιβάλλοντος (staging, production)
• Trunk-Based Development — ένα κλαδί + feature toggles, μέγιστο CI/CD, ελάχιστες συγχωνεύσεις
• One Flow — απλοποιημένο Git Flow χωρίς κλαδί develop, μόνο main + feature + release