Συγχώνευση κλαδιών — τι είναι, τρόποι συγχώνευσης και επίλυση συγκρούσεων

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

Το merge στο Git — είναι η λειτουργία συνδυασμού δύο ή περισσότερων ιστοριών ανάπτυξης σε μία. Όταν ένας προγραμματιστής συγχωνεύει ένα κλαδί, το Git βρίσκει αυτόματα τον κοινό πρόγονο (base commit) και δημιουργεί ένα νέο commit συγχώνευσης που περιλαμβάνει αλλαγές και από τα δύο κλαδιά. Three-way merge — ο τυπικός αλγόριθμος που συγκρίνει τρεις καταστάσεις: τον κοινό πρόγονο, το πρώτο κλαδί και το δεύτερο κλαδί.

Η διαδικασία merge ξεκινά με την εντολή git merge. Το Git καθορίζει το σημείο απόκλισης των κλαδιών και εφαρμόζει διαδοχικά τις αλλαγές από το κλαδί πηγή στο κλαδί προορισμού. Αν οι αλλαγές δεν έρχονται σε σύγκρουση, το Git εκτελεί fast-forward ή δημιουργεί merge commit ανάλογα με τις ρυθμίσεις. Fast-forward — το σενάριο όπου το κλαδί προορισμού απλά μετακινείται στα commits του κλαδιού πηγής.

# Μετάβαση στο κλαδί προορισμού και συγχώνευση
git checkout main
git merge feature/payment-module

# Συγχώνευση με ρητό no-fast-forward
git merge --no-ff feature/payment-module

# Ακύρωση συγχώνευσης αν οι συγκρούσεις είναι πολύ περίπλοκες
git merge --abort

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

Τρόποι συγχώνευσης κλαδιών

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

Το Standard merge δημιουργεί ένα merge commit με δύο γονείς. Η πλήρης ιστορία διατηρείται, αλλά το γράφημα διακλάδωσης γίνεται πιο περίπλοκο. Squash merge συνδυάζει όλα τα commits του feature κλαδιού σε ένα και το εφαρμόζει στο κλαδί προορισμού — η ιστορία γίνεται γραμμική και καθαρή, αλλά χάνεται η πληροφορία για τα ενδιάμεσα στάδια.

Το Rebase, αν και δεν είναι πλήρης συγχώνευση, επιτυγχάνει το ίδιο αποτέλεσμα — οι αλλαγές από το ένα κλαδί μεταφέρονται στο άλλο. Η διαφορά είναι ότι η ιστορία ξαναγράφεται: τα commits του feature κλαδιού δημιουργούνται εκ νέου πάνω από το τελευταίο commit του κλαδιού προορισμού. Αυτό δίνει μια ιδανικά γραμμική ιστορία, αλλά απαιτεί force push κατά την αποστολή.

Πώς να επιλύετε συγκρούσεις κατά το merge

Σύγκρουση κατά το merge προκύπτει όταν σε δύο κλαδιά έχουν αλλάξει οι ίδιες γραμμές ενός αρχείου. Το Git δεν μπορεί να καθορίσει αυτόματα ποια έκδοση να διατηρήσει και απαιτεί την παρέμβαση του προγραμματιστή. Οι συγκρούσεις εμφανίζονται στα αρχεία ως ειδικοί δείκτες: <<<<<<<, =======, >>>>>>>.

Η διαδικασία επίλυσης σύγκρουσης περιλαμβάνει διάφορα βήματα. Πρώτα, ο προγραμματιστής ανοίγει το αρχείο με τη σύγκρουση και επιλέγει χειροκίνητα τις απαραίτητες αλλαγές. Είναι σημαντικό να μην επιλέγει απλά μία από τις εκδόσεις, αλλά να κατανοεί τη λογική και των δύο αλλαγών και να παίρνει τη σωστή απόφαση. Μετά την επεξεργασία του αρχείου, οι δείκτες σύγκρουσης αφαιρούνται και οι αλλαγές προστίθενται στο staging area μέσω git add.

# Προβολή λίστας αρχείων με συγκρούσεις
git status

# Εκκίνηση mergetool (π.χ. VS Code, IntelliJ)
git mergetool

# Αφού επιλυθούν όλες οι συγκρούσεις
git add .
git merge --continue

# Ή ακύρωση της συγχώνευσης εντελώς
git merge --abort

Η χρήση οπτικών εργαλείων merge επιταχύνει σημαντικά την επίλυση συγκρούσεων. Τα VS Code, IntelliJ IDEA και GitKraken παρέχουν διεπαφές με τρία πάνελ: τρέχον κλαδί, εισερχόμενο κλαδί και αποτέλεσμα. Το εργαλείο git mergetool ανοίγει αυτόματα τον ρυθμισμένο επεξεργαστή για κάθε αρχείο με σύγκρουση.

Ο καλύτερος τρόπος για να αποφύγετε περίπλοκες συγκρούσεις είναι ο τακτικός συγχρονισμός του feature κλαδιού με το κύριο κλαδί. Αν ο προγραμματιστής συγχωνεύει το main στο κλαδί του μία φορά την ημέρα, οι συγκρούσεις θα είναι μικρές και εύκολα επιλύσιμες. Η συσσώρευση αλλαγών για μία εβδομάδα εγγυάται περίπλοκες συγκρούσεις με υψηλό κίνδυνο σφαλμάτων.

Πότε να χρησιμοποιείτε rebase αντί για merge

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

Το Rebase είναι κατάλληλο όταν ένας προγραμματιστής εργάζεται στο τοπικό του feature κλαδί και θέλει να αποκτήσει μια καθαρή γραμμική ιστορία πριν από τη δημιουργία Pull Request. Μετά το rebase, όλα τα commits ταξινομούνται σειριακά, χωρίς περιττά merge commits. Ωστόσο, το rebase απαιτεί force push και δεν εφαρμόζεται σε κλαδιά στα οποία εργάζονται πολλά άτομα ταυτόχρονα.

• Rebase — για προσωπικά feature κλαδιά όπου χρειάζεται καθαρή ιστορία
• Merge — για κοινά κλαδιά και καταγραφή της στιγμής συγχώνευσης
• Squash — όταν το feature κλαδί περιέχει πολλά μικρά working commits

Ο χρυσός κανόνας του Git: μη χρησιμοποιείτε rebase σε commits που έχουν ήδη σταλεί στο κοινό αποθετήριο. Αυτό εγγυάται ότι η ιστορία στο κοινό κλαδί παραμένει αμετάβλητη και άλλοι προγραμματιστές δεν θα συναντήσουν διπλότυπα ή χαμένα commits. Για την ενσωμάτωση του feature κλαδιού στο κύριο κλαδί, χρησιμοποιήστε merge μέσω Pull Request.

Βέλτιστες πρακτικές συγχώνευσης κλαδιών

Η σωστή διαδικασία merge — η βάση της σταθερής ανάπτυξης. Στη σύγχρονη ομαδική εργασία, το merge εκτελείται όχι μέσω κονσόλας, αλλά μέσω Pull Request στο GitHub ή Merge Request στο GitLab. Το PR περνά από code review, αυτόματους ελέγχους CI και μόνο τότε συγχωνεύεται στο κύριο κλαδί.

Πρώτη πρακτική — κάντε merge μόνο αφού περάσουν όλοι οι έλεγχοι. Το CI pipeline πρέπει να χτίσει το έργο, να εκτελέσει δοκιμές και να ελέγξει την ποιότητα κώδικα. Αν έστω και ένας έλεγχος δεν περάσει, το merge μπλοκάρεται. Οι σύγχρονες πλατφόρμες (GitHub, GitLab) έχουν ενσωματωμένη προστασία: οι branch protection rules μπλοκάρουν αυτόματα το merge σε αποτυχία CI.

Δεύτερη πρακτική — μην κάνετε ποτέ merge σπασμένου κώδικα. Πριν από το merge, ο προγραμματιστής πρέπει να βεβαιωθεί ότι οι αλλαγές του δεν σπάνε το build και δεν προκαλούν παλινδρόμηση στην υπάρχουσα λειτουργικότητα. Γι' αυτό υπάρχουν αυτοματοποιημένες δοκιμές και code review.

Τρίτη πρακτική — καθαρίστε τα feature κλαδιά μετά το merge. Το κλαδί που έχει ήδη συγχωνευθεί πρέπει να διαγραφεί. Αυτό αποτρέπει τη σύγχυση και τη συμφόρηση του αποθετηρίου. Το GitHub προσφέρει αυτόματα διαγραφή του κλαδιού μετά το merge του PR, και οι ρυθμίσεις του αποθετηρίου μπορούν να ρυθμιστούν για αυτόματη διαγραφή.