Rebase: τι είναι, σε τι διαφέρει από το Merge και αρχή λειτουργίας

Τι είναι το Rebase;

Rebase (αναβάθμιση βάσης) — είναι μια λειτουργία Git που μετακινεί commits από τον τρέχοντα κλάδο σε ένα νέο σημείο αναφοράς (βάση). Αντί να δημιουργεί commit συγχώνευσης, το rebase παίρνει κάθε commit από τον κλάδο προέλευσης και το εφαρμόζει διαδοχικά πάνω από τη νέα βάση. Το αποτέλεσμα είναι μια γραμμική ακολουθία commits χωρίς διακλαδώσεις.

Το όνομα rebase προέρχεται από το „re-base" — αλλαγή βάσης. Εάν το merge ενώνει δύο κλάδους σε ένα σημείο, το rebase στην πραγματικότητα μετακινεί ολόκληρο τον κλάδο σας σε μια νέα θέση, δημιουργώντας την ψευδαίσθηση ότι ξεκινήσατε την ανάπτυξη από την τρέχουσα κατάσταση του κλάδου-στόχου. Αυτό δημιουργεί την εντύπωση τέλειας διαδοχικής εργασίας.

Σύμφωνα με την Atlassian, 2025, οι ομάδες που χρησιμοποιούν rebase για κλάδους feature ξοδεύουν 30% λιγότερο χρόνο στην ανάλυση της ιστορίας commits σε σύγκριση με ομάδες που χρησιμοποιούν αποκλειστικά merge. Η γραμμική ιστορία απλοποιεί το git blame, bisect και την προβολή του αρχείου καταγραφής μέσω του git log --oneline.

Θεμελιώδης διαφορά από το Merge

Merge ενώνει κλάδους δημιουργώντας ένα commit με δύο γονείς. Rebase ξαναγράφει την ιστορία: νέα commits δημιουργούνται από την αρχή με νέα hashes, αν και οι αλλαγές σε αυτά είναι ίδιες με τα πρωτότυπα. Αυτό σημαίνει ότι το rebase αλλάζει τα αναγνωριστικά SHA των commits, κάτι που είναι κρίσιμο για δημόσιους κλάδους.

Πώς λειτουργεί το Rebase

Ο μηχανισμός rebase αποτελείται από τέσσερα βήματα: το Git καθορίζει τον κοινό πρόγονο (merge base) του τρέχοντος και του κλάδου-στόχου, στη συνέχεια εφαρμόζει διαδοχικά κάθε commit του τρέχοντος κλάδου πάνω από τον κλάδο-στόχο. Εάν σε κάποιο βήμα προκύψει σύγκρουση — το rebase σταματά και περιμένει λύση.

# Αρχική κατάσταση: το feature υστερεί κατά 3 commits από το develop
git checkout feature/new-login
git rebase develop

# Το Git παίρνει 3 commits από το feature και τα εφαρμόζει πάνω από το develop
# Εάν δεν υπάρχουν συγκρούσεις — το rebase ολοκληρώνεται αυτόματα
# Εάν υπάρχουν — το Git σταματά στο συγκρουσιακό commit

Μετά το rebase, ο κλάδος feature περιέχει όλα τα commits από το develop συν τα δικά του commits, που μοιάζουν με συνέχεια του develop. Αυτό επιτρέπει τη συγχώνευση στο develop μέσω fast-forward, χωρίς τη δημιουργία commit συγχώνευσης.

Διαδικασία βήμα προς βήμα

Ας εξετάσουμε ένα λεπτομερές παράδειγμα: ένας προγραμματιστής δημιούργησε έναν κλάδο feature από το develop, έκανε δύο commits, και στο μεταξύ άλλοι προγραμματιστές πρόσθεσαν τρία commits στο develop. Το rebase θα μετακινήσει τα δύο commits του feature σε μια νέα θέση, δημιουργώντας αντίγραφα με νέα SHA.

# 1. Δημιουργία κλάδου feature
git checkout -b feature/payment-refactor develop

# 2. Δημιουργία commits στο feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Ενημέρωση develop (εργασία συναδέλφων)
git checkout develop
git pull

# 4. Αναβάθμιση βάσης feature πάνω από το νέο develop
git checkout feature/payment-refactor
git rebase develop

# 5. Τώρα το feature μπορεί να συγχωνευθεί μέσω fast-forward
git checkout develop
git merge feature/payment-refactor

Εάν στο βήμα 4 προκύψει σύγκρουση, το Git σταματά στο προβληματικό commit. Ο προγραμματιστής επιλύει τη σύγκρουση, κάνει git add και εκτελεί git rebase --continue. Εάν χρειάζεται να παραλείψει ένα commit — git rebase --skip, εάν ακυρώσει ολόκληρο το rebase — git rebase --abort.

Αυτόματη παράλειψη κενών commits

Η σημαία --empty ελέγχει τη συμπεριφορά του rebase σε κενά commits — καταστάσεις όπου όλες οι αλλαγές του commit είναι ήδη παρούσες στον κλάδο-στόχο. Από προεπιλογή, το rebase σταματά και ζητά απόφαση. Με τη σημαία --empty=drop, το Git παραλείπει αυτόματα τέτοια commits χωρίς σταμάτημα, επιταχύνοντας τη μαζική αναβάθμιση βάσης με μεγάλο αριθμό commits.

Διαδραστικό Rebase

Interactive rebase (git rebase -i) — ένα ισχυρό εργαλείο για επεξεργασία της ιστορίας commits. Ανοίγει έναν επεξεργαστή με λίστα commits και βασικές εντολές: pick (διατήρηση), reword (αλλαγή μηνύματος), edit (αλλαγή περιεχομένου), squash (συγχώνευση με προηγούμενο), fixup (συγχώνευση χωρίς μήνυμα), drop (διαγραφή).

# Διαδραστικό rebase των τελευταίων 4 commits
git rebase -i HEAD~4

# Στον επεξεργαστή θα ανοίξει το σχέδιο rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Αλλάζουμε σε:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Αποτέλεσμα: τρία commits (οθόνη σύνδεσης, επικύρωση, διάταξη) συμπιέζονται σε ένα, και το commit με σχόλια διαγράφεται. Αυτό επιτρέπει την παρουσίαση μιας καθαρής ιστορίας χωρίς πρόχειρα και διορθώσεις για έλεγχο κώδικα. Το interactive rebase είναι το τυπικό εργαλείο προετοιμασίας ενός κλάδου feature πριν από το Pull Request.

Rebase vs Merge: σύγκριση

Rebase και Merge λύνουν την ίδια εργασία — ενσωμάτωση αλλαγών — αλλά με θεμελιωδώς διαφορετικούς τρόπους. Η επιλογή μεταξύ τους εξαρτάται από το ποια ιστορία θέλετε να βλέπετε στο git log και ποιος άλλος εργάζεται με τον κλάδο σας.

Πρακτικός κανόνας: χρησιμοποιείτε merge για ενσωμάτωση σε κοινούς κλάδους (develop, main) και rebase για ενημέρωση προσωπικών κλάδων feature στην τρέχουσα κατάσταση. Πολλές ομάδες συνδυάζουν: rebase feature στο develop, στη συνέχεια --no-ff merge στο develop.

Επίδραση στο git bisect

Git bisect — ένα εργαλείο για την εύρεση του commit που εισήγαγε μια παλινδρόμηση. Κατά τη χρήση merge, το git bisect περνά σωστά μέσα από τα commits συγχώνευσης, λαμβάνοντας υπόψη και τους δύο γονείς. Στο rebase, το bisect λειτουργεί ταχύτερα επειδή η ιστορία είναι γραμμική και δεν απαιτεί διακλάδωση. Ωστόσο, εάν το rebase έγινε αφού τα commits έγιναν γνωστά στην ομάδα, τα αρχικά SHA χάνονται και το bisect μπορεί να μην βρει το προβληματικό commit.

Πότε να εφαρμόζετε το Rebase

Rebase είναι βέλτιστο σε τρία σενάρια: προετοιμασία κλάδου feature για Pull Request, ενημέρωση προσωπικού κλάδου στην τρέχουσα κατάσταση main/develop και καθαρισμός ιστορίας πριν από τη συγχώνευση. Σε κάθε περίπτωση, το rebase βελτιώνει την αναγνωσιμότητα της ιστορίας χωρίς κίνδυνο για την ομαδική εργασία.

Πριν από ένα Pull Request συνιστάται η εκτέλεση interactive rebase για τη συγχώνευση commits εργασίας (WIP, διορθώσεις μετά από έλεγχο) σε ουσιαστικές λογικές ενότητες. Αυτό διευκολύνει τον έλεγχο κώδικα: ο επιθεωρητής βλέπει όχι 15 μικρά commits, αλλά 3-5 δομημένες αλλαγές με κατανοητά μηνύματα.

Για την ενημέρωση κλάδου feature, το rebase είναι προτιμότερο από το merge επειδή δεν δημιουργεί περιττά commits συγχώνευσης. Εάν περιοδικά κάνετε git rebase develop μέσα στον κλάδο feature, μετά την τελική συγχώνευση δεν θα υπάρχει καταρράκτης από 10 commits συγχώνευσης — μόνο καθαρά commits λειτουργίας πάνω από το develop.

Καθαρισμός ιστορίας μέσω interactive rebase πριν από τη συγχώνευση επιτρέπει την απόκρυψη μικρών διορθώσεων (τυπογραφικά λάθη, μορφοποίηση) και την ομαδοποίηση commits ανά λειτουργικότητα. Τα μηνύματα Git πρέπει να ακολουθούν τη σύμβαση Conventional Commits (fix:, feat:, refactor:, docs:), που δημιουργεί αυτόματο changelog.

Κίνδυνοι και κανόνες του Rebase

Rebase — μια επικίνδυνη λειτουργία εάν εφαρμοστεί λανθασμένα. Ο κύριος κίνδυνος — η επανεγγραφή της δημοσιευμένης ιστορίας. Εάν ένας προγραμματιστής κάνει rebase σε έναν κλάδο που άλλοι έχουν ήδη κάνει push και χρησιμοποιούν, τα τοπικά τους αντίγραφα αποσυγχρονίζονται και θα πρέπει να εκτελέσουν force-pull με κίνδυνο απώλειας δεδομένων.

• Χρυσός κανόνας: μην κάνετε ποτέ rebase σε commits που υπάρχουν ήδη στο κοινό αποθετήριο. Αυτό ισχύει για οποιονδήποτε κλάδο στον οποίο έχουν πρόσβαση άλλα μέλη της ομάδας
• Force push: μετά από rebase τοπικού κλάδου feature, απαιτείται push με τη σημαία --force-with-lease, η οποία είναι ασφαλέστερη από το --force επειδή ελέγχει εάν κάποιος ενημέρωσε τον κλάδο στον διακομιστή
• Απώλεια πλαισίου: το rebase καταστρέφει πληροφορίες σχετικά με το πότε και από ποιον κλάδο δημιουργήθηκε ο κλάδος feature. Εάν είναι σημαντικό να διατηρηθούν οι ημερομηνίες δημιουργίας του κλάδου — χρησιμοποιήστε merge
• Συγκρούσεις: στο rebase, οι συγκρούσεις πρέπει να επιλύονται για κάθε commit ξεχωριστά, κάτι που μπορεί να είναι κουραστικό με μεγάλο αριθμό commits

Για την ελαχιστοποίηση κινδύνων, ακολουθήστε τον κανόνα: rebase μόνο για προσωπικούς κλάδους που δεν έχουν δημοσιευθεί. Εάν ο κλάδος είναι ήδη στο κοινό αποθετήριο — χρησιμοποιήστε merge με --no-ff. Εάν είναι απαραίτητο το rebase ενός δημοσιευμένου κλάδου — προειδοποιήστε την ομάδα και συντονίστε το force push εκ των προτέρων.

Αυτόματη προστασία από επικίνδυνο rebase υλοποιείται μέσω server-side hooks: το pre-receive hook στην πλευρά του διακομιστή Git μπορεί να ελέγχει εάν το push ξαναγράφει δημοσιευμένα commits. Το GitHub και το GitLab παρέχουν ενσωματωμένη προστασία για προστατευμένους κλάδους — το force push μπλοκάρεται εκτός εάν η προστασία αφαιρεθεί από τον διαχειριστή.