Release Branch στο Git — τι είναι, σκοπός και διαδικασία εργασίας

Τι είναι το Release Branch στο Git

Release Branch (branch έκδοσης) — είναι ένα προσωρινό branch στο Git Flow, που δημιουργείται από το develop όταν η ομάδα αποφασίζει ότι το τρέχον σύνολο λειτουργιών είναι έτοιμο για κυκλοφορία. Υπάρχει ακριβώς όσο διαρκεί η τελική προετοιμασία της έκδοσης — από μερικές ώρες έως μερικές ημέρες.

Ο κύριος σκοπός του release branch — να παγώσει ένα συγκεκριμένο σύνολο λειτουργιών για την έκδοση, χωρίς να σταματήσει την ανάπτυξη των επόμενων εκδόσεων. Ενώ το release branch προετοιμάζεται για κυκλοφορία, άλλοι προγραμματιστές μπορούν να συνεχίσουν να συγχωνεύουν feature branches στο develop για την επόμενη έκδοση.

Στο release branch δεν δημιουργούνται νέες λειτουργίες — μόνο διορθώσεις σφαλμάτων, ενημέρωση έκδοσης εφαρμογής, εντοπισμός και τεκμηρίωση. Μετά την ολοκλήρωση όλων των εργασιών, το release branch συγχωνεύεται στο main (σηματοδοτείται ως έκδοση) και πίσω στο develop (για να περάσουν οι διορθώσεις σφαλμάτων σε μελλοντικές εκδόσεις).

Σύμφωνα με το Atlassian, 2024, τα release branches είναι κρίσιμα για έργα με τακτικούς κύκλους έκδοσης — εξασφαλίζουν προβλεψιμότητα και σταθερότητα της διαδικασίας κυκλοφορίας.

Κύκλος ζωής του release branch

Κύκλος ζωής του release branch από τη δημιουργία έως τη διαγραφή περιλαμβάνει διάφορα στάδια. Η κατανόηση κάθε σταδίου βοηθά την ομάδα να συγχρονίσει τις ενέργειες και να αποφύγει λάθη.

1. Δημιουργία — από το τελευταίο commit του develop δημιουργείται ένα branch με όνομα release/2.5.0. Το develop συνεχίζει να δέχεται feature branches για την επόμενη έκδοση.
2. Προετοιμασία — στο release branch ενημερώνεται η έκδοση της εφαρμογής στο build.gradle, Info.plist και άλλα αρχεία παραμέτρων.
3. Διόρθωση σφαλμάτων — διορθώνονται κρίσιμα σφάλματα που βρέθηκαν κατά την τελική δοκιμή. Μόνο σφάλματα — χωρίς νέες λειτουργίες.
4. Τελική δοκιμή — η ομάδα QA διεξάγει δοκιμές παλινδρόμησης στο release branch. Νέα σφάλματα αποστέλλονται για διόρθωση στο ίδιο branch.
5. Συγχώνευση στο main — το release branch συγχωνεύεται στο main με τη σημαία --no-ff. Δημιουργείται η ετικέτα έκδοσης: v2.5.0.
6. Συγχώνευση στο develop — το release branch συγχωνεύεται πίσω στο develop, ώστε οι διορθώσεις σφαλμάτων από την έκδοση να περάσουν στην τρέχουσα ανάπτυξη.
7. Διαγραφή — το release branch διαγράφεται τοπικά και απομακρυσμένα, καθώς η αποστολή του έχει ολοκληρωθεί.

Το σημείο 6 — αντίστροφη συγχώνευση στο develop — συχνά ξεχνιέται, αλλά είναι κρίσιμο. Χωρίς αυτό, οι διορθώσεις σφαλμάτων που έγιναν στο release δεν θα περάσουν στο develop, και στην επόμενη έκδοση τα ίδια σφάλματα μπορεί να εμφανιστούν ξανά.

Τυπικές διάρκειες σταδίων του release branch

Η διάρκεια ζωής του release branch εξαρτάται από την πολυπλοκότητα της έκδοσης και την ποιότητα του κώδικα στο develop. Κατά μέσο όρο, η προετοιμασία διαρκεί από 2 έως 5 εργάσιμες ημέρες για μια εφαρμογή κινητού μεσαίου μεγέθους.

Τι γίνεται στο release branch

Στο release branch εκτελείται ένα αυστηρά περιορισμένο σύνολο εργασιών. Οποιαδήποτε απόκλιση από αυτήν τη λίστα παραβιάζει το μοντέλο Git Flow και δημιουργεί κινδύνους για τη σταθερότητα της έκδοσης.

Ο κανόνας απαγόρευσης νέων λειτουργιών — ο σημαντικότερος στο release branch. Εάν μια λειτουργία δεν πρόλαβε την έκδοση, περιμένει τον επόμενο κύκλο. Η προσπάθεια να προωθηθεί μια ημιτελής λειτουργία στο release branch — η κύρια αιτία καθυστερήσεων και σφαλμάτων στην παραγωγή.

Ενημέρωση έκδοσης σε έργο κινητού

Στο release branch ενημερώνεται υποχρεωτικά ο αριθμός έκδοσης της εφαρμογής. Για Android, αυτά είναι τα πεδία versionCode και versionName στο build.gradle, για iOS — το CFBundleShortVersionString στο Info.plist.

// build.gradle (app-level) — ενημέρωση έκδοσης στο release branch
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Για iOS — ενημέρωση Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Διαφορές μεταξύ release και hotfix

Οι αρχάριοι προγραμματιστές συχνά μπερδεύουν τα release και hotfix branches, αν και ο σκοπός τους είναι θεμελιωδώς διαφορετικός. Ένα λάθος στην επιλογή του τύπου branch μπορεί να οδηγήσει σε καθυστέρηση μιας κρίσιμης διόρθωσης ή διακοπή της διαδικασίας έκδοσης.

• Πηγή — το release δημιουργείται από το develop, το hotfix — από το main. Αυτή είναι η κύρια διαφορά που καθορίζει όλα τα υπόλοιπα.
• Επείγον — το release είναι προγραμματισμένο: η ομάδα αποφασίζει η ίδια πότε θα ξεκινήσει την προετοιμασία. Το hotfix είναι επείγον: ένα πρόβλημα στην παραγωγή απαιτεί άμεση διόρθωση.
• Περιεχόμενο — το release μπορεί να περιλαμβάνει πολλές διορθώσεις και ενημέρωση έκδοσης. Το hotfix περιέχει μόνο μία κρίσιμη διόρθωση.
• Συγχώνευση — το release συγχωνεύεται στο main και το develop. Το hotfix συγχωνεύεται επίσης στο main και το develop, αλλά κατά προτεραιότητα.
• Διάρκεια ζωής — το release ζει από 1 έως 7 ημέρες. Το hotfix ζει από 30 λεπτά έως 1 ημέρα.

Εάν ένα σφάλμα ανακαλυφθεί κατά τη διαδικασία προετοιμασίας της έκδοσης (στο release branch) — είναι μια συνηθισμένη διόρθωση σφάλματος. Εάν ένα σφάλμα ανακαλυφθεί στην παραγωγή (στο main) — είναι hotfix και δημιουργείται από το main, ακόμα κι αν το release branch υπάρχει ήδη.

Κανόνες ονομασίας release branches

Ένα ενιαίο πρότυπο ονομασίας release branches απλοποιεί την πλοήγηση στο αποθετήριο και επιτρέπει στα συστήματα CI/CD να καθορίζουν αυτόματα ότι το branch ανήκει στη διαδικασία έκδοσης.

• release/X.Y.Z — τυπική μορφή Git Flow, όπου X.Y.Z είναι η έκδοση. Παράδειγμα: release/2.5.0.
• release/όνομα — εναλλακτική μορφή με κωδική ονομασία έκδοσης. Παράδειγμα: release/merlin.
• release/ημερομηνία — μορφή με ημερομηνία έκδοσης. Χρησιμοποιείται σπάνια, καθώς η έκδοση είναι πιο σημαντική από την ημερομηνία. Παράδειγμα: release/2024-12-01.

Η μορφή release/X.Y.Z — προτιμάται, καθώς συνδέει ρητά το branch με τον αριθμό έκδοσης που θα αποδοθεί στην έκδοση. Αυτό απλοποιεί την αναζήτηση και την αυτόματη επεξεργασία από σενάρια CI/CD.

Στρατηγική αντίστροφης συγχώνευσης στο develop

Αντίστροφη συγχώνευση (merge back) του release branch στο develop — μία από τις πιο σημαντικές και ταυτόχρονα συχνά παραβλεπόμενες λειτουργίες. Χωρίς αυτήν, όλες οι διορθώσεις σφαλμάτων που έγιναν στο release παραμένουν μόνο στην έκδοση και δεν εισέρχονται στον επόμενο κύκλο έκδοσης.

Η διαδικασία αντίστροφης συγχώνευσης εκτελείται αφού το release branch έχει ήδη συγχωνευθεί στο main. Πρώτα το release συγχωνεύεται στο develop, στη συνέχεια — διαγράφεται. Αυτό εγγυάται ότι το develop περιέχει όλες τις διορθώσεις που έγιναν κατά την προετοιμασία της έκδοσης.

Μετά την αντίστροφη συγχώνευση είναι πιθανές συγκρούσεις — ειδικά αν στο develop έχουν ήδη εμφανιστεί νέα feature branches που τροποποίησαν τα ίδια αρχεία. Ο προγραμματιστής που είναι υπεύθυνος για την έκδοση επιλύει αυτές τις συγκρούσεις και ωθεί το develop στον διακομιστή.

Ορισμένες ομάδες χρησιμοποιούν rebase αντί για merge για αντίστροφη συγχώνευση, ώστε το ιστορικό να παραμένει γραμμικό. Ωστόσο, το merge είναι ασφαλέστερο για το develop, καθώς δεν ξαναγράφει το ιστορικό commits που μπορεί να έχουν ήδη χρησιμοποιηθεί από άλλους προγραμματιστές.

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

Ας εξετάσουμε τον πλήρη κύκλο εργασίας με το release branch: από τη δημιουργία έως τη διαγραφή μετά την επιτυχή κυκλοφορία της εφαρμογής κινητού έκδοσης 2.5.0.

# 1. Δημιουργία release branch από το develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Ενημέρωση έκδοσης και διορθώσεις σφαλμάτων
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Διόρθωση σφαλμάτων (μόνο bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Αποστολή release branch στον διακομιστή
git push origin release/2.5.0

# 5. Συγχώνευση release στο main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Αντίστροφη συγχώνευση στο develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Διαγραφή release branch
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Οι εντολές 5 και 6 — διπλή συγχώνευση — είναι κρίσιμες. Πρώτα το main λαμβάνει τον κώδικα έκδοσης και την ετικέτα, στη συνέχεια το develop συγχρονίζεται με τις διορθώσεις σφαλμάτων από το release. Εάν παραλειφθεί το βήμα 6, οι διορθώσεις από την έκδοση δεν θα περάσουν στον επόμενο κύκλο ανάπτυξης.

Αυτοματοποίηση διαδικασίας έκδοσης

Για έργα κινητού με τακτικές εκδόσεις, η διαδικασία δημιουργίας release branch και ενημέρωσης έκδοσης μπορεί να αυτοματοποιηθεί μέσω σεναρίων CI/CD. Το GitHub Actions επιτρέπει τη δημιουργία ενός workflow που, με το πάτημα ενός κουμπιού, δημιουργεί ένα release branch με αυτόματη ενημέρωση έκδοσης.

Για έργα κινητού με τακτικές εκδόσεις, η διαδικασία δημιουργίας release branch και ενημέρωσης έκδοσης μπορεί να αυτοματοποιηθεί μέσω σεναρίων CI/CD. Το GitHub Actions επιτρέπει τη δημιουργία ενός workflow που, με το πάτημα ενός κουμπιού, δημιουργεί ένα release branch με αυτόματη ενημέρωση έκδοσης.

# GitHub Actions — αυτοματοποίηση δημιουργίας release branch
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}