Rebase: τι είναι, πώς λειτουργεί και εργασία με Git

Τι είναι το rebase στο Git

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

Βασική σύνταξη: git rebase main — όντας στον feature-κλάδο, αυτή η εντολή μεταφέρει όλα τα feature commits στην κορυφή του main. Το Git χρησιμοποιεί στρατηγική three-way merge για κάθε commit ξεχωριστά. Εάν το commit A υπάρχει ήδη στον κλάδο-στόχο (προσδιορίζεται από το hash), το Git το παραλείπει αυτόματα, αποφεύγοντας την αντιγραφή αλλαγών.

Το rebase υποστηρίζει επίσης τη λειτουργία onto για μεταφορά μέρους των commits: git rebase --onto target start end — αυτή η μορφή επιτρέπει την εξαγωγή ενός εύρους commits από έναν κλάδο και την εφαρμογή τους πάνω σε έναν άλλο. Για παράδειγμα, το git rebase --onto main feature~3 feature θα μεταφέρει τα τελευταία τρία commits του feature-κλάδου στην κορυφή του main.

# Μετάβαση στον feature κλάδο
git checkout feature

# Αναβάση του feature στο main
git rebase main

# Μετά από επιτυχημένο rebase — η ιστορία είναι γραμμική
git log --oneline --graph

# Μεταφορά των τελευταίων 3 commits στο main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: βασικές διαφορές

Rebase και merge λύνουν την ίδια εργασία — συνδυασμό αλλαγών από διαφορετικούς κλάδους — αλλά το κάνουν με θεμελιωδώς διαφορετικούς τρόπους. Το merge διατηρεί την πλήρη ιστορία συγχωνεύσεων, δημιουργώντας ένα merge-commit με δύο γονείς. Το rebase ξαναγράφει την ιστορία, καθιστώντας την γραμμική. Η επιλογή μεταξύ τους εξαρτάται από τη ροή εργασίας της ομάδας και τους κανόνες εργασίας με το αποθετήριο.

Η κύρια διαφορά — πώς καταγράφεται το γεγονός της συγχώνευσης. Το merge διατηρεί: “σε αυτό το σημείο συγχωνεύσαμε το feature στο main” — αυτό είναι πληροφοριακό για την ιστορία του έργου, αλλά μολύνει το αρχείο καταγραφής σε συχνές συγχωνεύσεις. Το rebase δείχνει: “τα feature commits έγιναν διαδοχικά από την τελευταία κατάσταση του main” — αυτό είναι καθαρό, αλλά κρύβει το γεγονός ότι η εργασία γινόταν παράλληλα.

Η δεύτερη διαφορά — χειρισμός συγκρούσεων. Στο merge, οι συγκρούσεις επιλύονται μία φορά και η λύση καταγράφεται στο merge-commit. Στο rebase, οι συγκρούσεις μπορεί να προκύψουν για κάθε μεταφερόμενο commit και κάθε μία απαιτεί ξεχωριστή επίλυση. Αυτό είναι πιο χρονοβόρο, αλλά επιτρέπει ακριβέστερο έλεγχο του ποιες αλλαγές εισέρχονται στην τελική έκδοση.

Διαδραστικό rebase: εντολές και σημαίες

Διαδραστικό rebase (git rebase -i) — είναι η λειτουργία κατά την οποία το Git ανοίγει έναν επεξεργαστή με λίστα commits και διαθέσιμες ενέργειες για κάθε ένα από αυτά. Ο προγραμματιστής μπορεί να ξαναγράψει την ιστορία πριν την αποστολή στο απομακρυσμένο αποθετήριο. Αυτό είναι το κύριο εργαλείο για τη διατήρηση της καθαρότητας των commits στον feature-κλάδο.

Διαθέσιμες εντολές στη διαδραστική λειτουργία: pick (άφησε το commit ως έχει), reword (άλλαξε το μήνυμα του commit), edit (σταμάτησε για αλλαγές), squash (συγχώνευσε με το προηγούμενο commit, διατηρώντας και τα δύο μηνύματα), fixup (συγχώνευσε απορρίπτοντας το μήνυμα), drop (διαγραφή commit). Κάθε εντολή αναφέρεται μπροστά από το hash του commit στον ανοιχτό επεξεργαστή.

Squash και fixup — οι πιο συχνά χρησιμοποιούμενες εντολές για συγχώνευση commits. Εάν ο προγραμματιστής έκανε 5 μικρά commits με διορθώσεις κατά τη διάρκεια της εργασίας, το squash θα τα συνδυάσει σε ένα λογικό commit με ουσιαστικό μήνυμα. Το fixup είναι χρήσιμο για τη διόρθωση τυπογραφικών λαθών: οι αλλαγές εισέρχονται στο προηγούμενο commit χωρίς να αποθηκεύεται το δικό τους μήνυμα.

# Άνοιγμα επεξεργαστή για τα τελευταία 4 commits
git rebase -i HEAD~4

# Ο επεξεργαστής θα εμφανίσει:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# Μετά την αποθήκευση — το Git εκτελεί rebase
# και ανοίγει επεξεργαστή για το συγχωνευμένο μήνυμα commit

# Auto-squash χωρίς άνοιγμα επεξεργαστή
git rebase -i HEAD~4 --autosquash

Η σημαία --autosquash ορίζει αυτόματα fixup/squash για commits των οποίων τα μηνύματα ξεκινούν με fixup! ή squash!. Επιταχύνει την εργασία εάν ο προγραμματιστής επισημαίνει εκ των προτέρων commits για μεταγενέστερη συγχώνευση. Η σημαία --committer-date-is-author-date διατηρεί την αρχική ημερομηνία του commit κατά την αναβάση — χρήσιμο για τη διατήρηση της χρονολογίας στην ιστορία.

Επίλυση συγκρούσεων κατά το rebase

Συγκρούσεις κατά το rebase προκύπτουν όταν το Git δεν μπορεί να εφαρμόσει αυτόματα το μεταφερόμενο commit λόγω αντιφάσεων με αλλαγές στον κλάδο-στόχο. Σε αντίθεση με το merge, όπου η σύγκρουση επιλύεται μία φορά, στο rebase κάθε commit μπορεί να προκαλέσει σύγκρουση και πρέπει να επιλύεται διαδοχικά για κάθε commit από το παλαιότερο στο νεότερο.

Όταν προκύπτει μια σύγκρουση, το Git διακόπτει το rebase και αναφέρει ποιο commit προκάλεσε το πρόβλημα. Ο προγραμματιστής ανοίγει το αρχείο με τη σύγκρουση (το Git επισημαίνει τις περιοχές σύγκρουσης με δείκτες <<<<<<<, =======, >>>>>>>), το επεξεργάζεται, το προσθέτει στο ευρετήριο (git add) και συνεχίζει το rebase με την εντολή git rebase --continue. Εάν δεν βρεθεί λύση — το git rebase --abort ακυρώνει πλήρως την αναβάση.

Συμβουλή: σε πολλαπλές συγκρούσεις, είναι πιο αποτελεσματικό να χρησιμοποιείτε το git mergetool, το οποίο ανοίγει έναν οπτικό επεξεργαστή για την επίλυση αντιφάσεων. Μπορείτε επίσης να παραλείψετε το προβληματικό commit (git rebase --skip), αλλά αυτό θα αφαιρέσει τις αλλαγές του από την τελική ιστορία, κάτι που σπάνια είναι η σωστή λύση.

# Έναρξη rebase με σύγκρουση
git rebase main
# Auto-merging file.txt
# ΣΥΓΚΡΟΥΣΗ (περιεχόμενο): Σύγκρουση συγχώνευσης στο file.txt

# Έλεγχος κατάστασης
git status
# και τα δύο τροποποιημένα: file.txt

# Επεξεργασία τμημάτων σύγκρουσης → git add → συνέχεια
git add file.txt
git rebase --continue

# Σε περίπτωση αμφιβολίας — ακύρωση
git rebase --abort

Πότε δεν πρέπει να κάνετε rebase

Χρυσός κανόνας rebase: μην κάνετε ποτέ rebase σε commits που έχουν ήδη σταλεί στο απομακρυσμένο αποθετήριο και είναι διαθέσιμα σε άλλους προγραμματιστές. Επειδή το rebase ξαναγράφει τα hash των commits, οι συνάδελφοι θα αντιμετωπίσουν συγκρούσεις κατά την προσπάθεια συγχρονισμού — η τοπική τους ιστορία θα έρχεται σε αντίθεση με την ξαναγραμμένη απομακρυσμένη.

Η κατάσταση στην οποία το rebase είναι κατηγορηματικά απαγορευμένο: εάν κάποιος έχει ήδη δημιουργήσει έναν κλάδο βασισμένο στα commits σας (για παράδειγμα, ο συνάδελφός σας έκανε ένα feature από το feature σας), η αλλαγή της ιστορίας θα καταστρέψει τη δουλειά του. Σε τέτοιες περιπτώσεις, πρέπει να χρησιμοποιείται merge. Επίσης, δεν συνιστάται να κάνετε rebase ακριβώς πριν από την προθεσμία — ένα λάθος κατά την επίλυση συγκρούσεων μπορεί να διαρκέσει περισσότερο από το αναμενόμενο και να μπλοκάρει την έκδοση.

Εξαίρεση: εάν ο κλάδος χρησιμοποιείται μόνο από έναν προγραμματιστή (προσωπικός feature-κλάδος, μη δημοσιευμένος ή δημοσιευμένος σε λειτουργία draft), το rebase πριν από το push είναι συνήθης πρακτική. Μετά τη δημοσίευση και την έναρξη συλλογικής εργασίας — μόνο merge. Το GitHub και το GitLab προσφέρουν από προεπιλογή το squash merge ως συμβιβασμό: συνδυάζει τα commits σε ένα, αλλά δεν ξαναγράφει την ιστορία του κλάδου-στόχου.

• Δημόσιοι κλάδοι (main, develop, release) — το rebase απαγορεύεται πλήρως.
• Ξένα commits — εάν ο κλάδος περιέχει commits άλλου προγραμματιστή, το rebase είναι απαράδεκτο.
• Πριν από την έκδοση — ο κίνδυνος συγκρούσεων είναι υψηλότερος: το merge είναι ασφαλέστερο μία ημέρα πριν από την προθεσμία.
• Κλάδοι με ετικέτες — η μετακίνηση commit με ετικέτα παραβιάζει τις συμβάσεις σημασιολογικής έκδοσης.
• CI/CD συνδεδεμένο με hash — ορισμένα συστήματα ανάπτυξης αναγνωρίζουν builds βάσει του hash του commit· το rebase θα σπάσει την παρακολούθηση.

Πρακτική ροή εργασίας με rebase

Στις σύγχρονες ομάδες, χρησιμοποιείται συχνότερα η ροή εργασίας προσανατολισμένη στο rebase σε συνδυασμό με το GitHub Flow. Η διαδικασία έχει ως εξής: ο προγραμματιστής δημιουργεί έναν feature-κλάδο από το main, εργάζεται σε αυτόν, συγχρονίζεται περιοδικά μέσω git rebase main και πριν από τη δημιουργία pull request εκτελεί ένα διαδραστικό rebase για τον καθαρισμό της ιστορίας.

Μετά τη δημιουργία PR (εάν χρειάζεται να ληφθούν νέες αλλαγές από το main) χρησιμοποιείται git pull --rebase main αντί του συνηθισμένου git pull. Αυτό επιτρέπει τη λήψη αλλαγών χωρίς τη δημιουργία περιττού merge-commit. Το git pull με τη σημαία --rebase είναι ισοδύναμο με git fetch + git rebase — το Git πρώτα φορτώνει νέα commits και στη συνέχεια αλλάζει τη βάση των τοπικών αλλαγών πάνω τους.

Το Git επιτρέπει τη ρύθμιση του rebase ως προεπιλεγμένης συμπεριφοράς για το pull: git config --global pull.rebase true. Μετά από αυτήν τη διαμόρφωση, το git pull εκτελεί πάντα rebase αντί για merge. Εάν χρειάζεται συνηθισμένο pull — χρησιμοποιείται git pull --no-rebase. Πολλές ομάδες ενεργοποιούν επίσης το autostash: git config --global rebase.autoStash true — αυτό κρύβει αυτόματα τις μη δεσμευμένες αλλαγές πριν από το rebase και τις επαναφέρει μετά.