3.2 Διακλαδώσεις στο Git - Βασικές έννοιες διακλαδώσεων και συγχωνεύσεων

Αρχικά ας υποθέσουμε ότι δουλεύουμε σε ένα έργο και έχουμε κάνει ήδη μερικές υποβολές στον κλάδο master.

Αποφασίσαμε ότι θα δουλέψουμε στο πρόβλημα #53 του συστήματος παρακολούθησης προβλημάτων που χρησιμοποιεί η εταιρία μας. Για να δημιουργήσουμε έναν κλάδο και μεταβούμε σε αυτόν συγχρόνως, μπορούμε να τρέξουμε την εντολή git checkout με την επιλογή -b:

Η παραπάνω εντολή είναι συντομογραφία για τις:

Επεξεργαζόμαστε την ιστοσελίδα μας και κάνουμε μερικές υποβολές. Με τις υποβολές ο κλάδος iss53 ωθείται, διότι τον έχουμε κάνει checkout (με άλλα λόγια έχουμε μεταβεί σε αυτόν), δηλαδή ο HEAD δείχνει σε αυτόν τον κλάδο:

Τώρα λαμβάνουμε το τηλεφώνημα ότι υπάρχει ένα άλλο επείγον πρόβλημα στην ιστοσελίδα και πρέπει να το αντιμετωπίσουμε άμεσα. Χάρη στο Git, δεν είναι απαραίτητο να αναπτύξουμε την επίλυση του προβλήματος παράλληλα με τις αλλαγές που έχουμε κάνει στον κλάδο iss53 και δεν χρειάζεται να καταβάλλουμε μεγάλη προσπάθεια ώστε να αναιρέσουμε όλες τις αλλαγές που έχουμε κάνει και να δουλέψουμε στο επείγον πρόβλημα και να εφαρμόσουμε τη λύση μας σε ό,τι βρίσκεται εκείνη τη στιγμή στη γραμμή της παραγωγής. Το μόνο που έχουμε να κάνουμε είναι να μεταβούμε στον κλάδο master.

Ωστόσο πρέπει να τονιστεί ότι αν πριν το κάνουμε αυτό υπάρχουν στον κατάλογο εργασίας μας ή στο στάδιο καταχώρισης αλλάγες που δεν έχουν υποβληθεί και έρχονται σε σύγκρουση με τον κλάδο στον οποίο θέλουμε να μεταβούμε, το Git δεν θα μας αφήσει να αλλάξουμε κλάδο. Το καλύτερο είναι να έχουμε μία καθαρή κατασταση εργασίας όταν μεταβαίνουμε από έναν κλάδο σε άλλο. Υπάρχουν τρόποι να παρακάμψουμε αυτήν τη συμπεριφορά (με τις εντολές git stash και git commit -amend που θα καλύψουμε στη συνέχεια, στην ενότητα stash και clean. Προς το παρόν, ας υποθέσουμε ότι έχουμε υποβάλλει όλες τις αλλαγές μας, ώστε να μπορούμε να μεταβαίνουμε από και προς τον κλάδο master χωρίς προβλήματα:

Σε αυτό το σημείο, ο κατάλογος εργασίας του έργου μας βρίσκεται ακριβώς στην κατάσταση στην οποία βρισκόταν πριν ξεκινήσουμε να δουλεύουμε για το πρόβλημα #53 και μπορούμε να εστιάσουμε στην επίλυση του επείγοντος προβλήματος. Αυτό είναι ένα σημαντικό σημείο που αξίζει να θυμόμαστε: όταν μεταπηδούμε από έναν κλάδο σε άλλο, το Git επαναφέρει τον κατάλογο εργασίας στην κατάσταση που είχε την τελευταία φορά που είχατε κάνει υποβολή σε αυτόν τον κλάδο. Προσθέτει, διαγράφει και τροποποιεί αρχεία αυτόματα ώστε να βεβαιωθεί ότι το αντίγραφο εργασίας μας είναι ίδιο με την κατάσταση του κλάδου αμέσως μετά την τελευταία υποβολή σε αυτόν τον κλάδο.

Στη συνέχεια, πρέπει να δουλέψουμε στο επείγον πρόβλημα. Ας φτιάξουμε έναν κλάδο hotfix στον οποίο θα δουλέψουμε μέχρι να το λύσουμε:

Τώρα μπορούμε να τρέξουμε τις δοκιμές μας, να βεβαιωθούμε ότι ο κώδικάς μας κάνει αυτό που θέλουμε, να τον συγχωνεύσουμε με τον κλάδο master και να τον ωθήσουμε στην παραγωγή. Το τελευταίο το κάνουμε με την εντολή git merge:

Σε αυτήν τη συγχώνευση υπάρχει η έκφραση fast-forward. Επειδή η υποβολή στην οποία έδειχνε ο κλάδος τον οποίο συγχωνεύσαμε ήταν αμέσως μετά την υποβολή στην οποία βρισκόμαστε τώρα, το Git απλά μετατοπίζει τον δείκτη προς τα μπροστά. Με άλλα λόγια όταν προσπαθούμε να συγχωνεύσουμε μία υποβολή με μία άλλη υποβολή στην οποία μπορούμε να φτάσουμε ακολουθώντας το ιστορικό της πρώτης, το Git απλοποιεί τη διαδικασία ωθώντας τον δείκτη σε εκείνο το σημείο, διότι δεν υπάρχει άλλη αποκλίνουσα εργασία που θα πρέπει να συγχωνευτεί —αυτό ονομάζεται “ταχυπροώθηση” (“fast-forward”).

Η αλλαγή μας τώρα υπάρχει στο στιγμιότυπο της υποβολής στην οποία δείχνει ο κλάδος master και μπορούμε να ωθήσουμε το επίθεμά μας.

Αφού ο σημαντικότατος διορθωτικός μας κώδικας έχει ωθηθεί στην παραγωγή, είμαστε έτοιμοι να επανέλθουμε στην εργασία την οποία κάνατε πριν μας διακόψει το τηλεφώνημα. Πριν όμως συνεχίσουμε, θα διαγράψουμε τον κλάδο hotfix, διότι δεν τον χρειάζόμαστε πλέον —ο κλάδος master δείχνει ακριβώς στην ίδια θέση. Μπορούμε να τον διαγράψουμε με την επιλογή -d στην εντολή git branch:

Τώρα μπορούμε να επανέλθουμε στον κλάδο εργασίας του προβλήματος #53 και να συνεχίσουμε να δουλεύουμε σ' αυτό.

Σε αυτό το σημείο αξίζει να σημειωθεί ότι οι αλλαγές που κάναμε στον κλάδο hotfix δεν περιέχονται στα αρχεία του κλάδου iss53. Αν θέλουμε να τα ενσωματώσουμε, μπορούμε να συγχωνεύσουμε τον κλάδο master στον κλάδο iss53 τρέχοντας την εντολή git merge master ή μπορούμε να αναβάλουμε την ενσωμάτωση αυτών των αλλαγών μέχρι να αποφασίσουμε να έλξουμε τον κλάδο iss53 μέσα στον κλάδο master αργότερα.

Ας υποθέσουμε τώρα ότι έχουμε αποφασίσει ότι η εργασία μας για το πρόβλημα #53 έχει ολοκληρωθεί και είναι έτοιμη να συγχωνευτεί στον κλάδο master. Για να το κάνουμε αυτό, αρκεί να συγχωνεύσουμε τον κλάδο iss53 στον κλάδο master, λίγο-πολύ με τον ίδιο τρόπο που συγχωνεύσατε τον κλάδο hotfix προηγουμένως. Το μόνο που έχουμε να κάνουμε είναι να μεταβούμε στον κλάδο στον οποίο θέλουμε να ενσωματώσουμε τον άλλο κλάδο και να τρέξουμε την εντολή git merge:

Το μήνυμα στην οθόνη διαφέρει λίγο από εκείνο που πήραμε όταν συγχωνεύσαμε τον κλάδο hotfix προηγουμένως. Σε αυτήν την περίπτωση, το ιστορικό των αλλαγών απέκλινε σε κάποιο παλιότερο σημείο. Επειδή η υποβολή στον κλάδο στον οποίο βρίσκόμαστε δεν είναι άμεσος πρόγονος του κλάδου τον οποίο ενσωματώνουμε, το Git πρέπει να κάνει λίγη δουλίτσα. Σε αυτήν την περίπτωση, το Git κάνει μία απλή τριμερή συγχώνευση, χρησιμοποιώντας τα στιγμιότυπα στο τέλος του κάθε κλάδου και τον κοινό πρόγονο των δύο.

Αντί, λοιπόν, το Git να μετακινήσει τον δείκτη του κλάδου προς τα εμπρός, δημιουργεί ένα νέο στιγμιότυπο που προκύπτει από αυτήν την τριμερή συγχώνευση και αυτόμάτως δημιουργεί μία νέα υποβολή που δείχνει σε αυτήν τη συγχώνευση. Αυτό ονομάζεται υποβολή συγχώνευσης (merge commit) και έχει την ιδιαιτερότητα ότι έχει περισσότερους από έναν γονείς.

Αξίζει να σημειωθεί ότι το ίδιο το Git αποφασίζει ποιος είναι ο κοινός πρόγονος που αποτελεί την καλύτερη δυνατή βάση για τη συγχώνευση· αυτή είναι μία διαφορά ανάμεσα στο Git και παλιότερα εργαλεία όπως το CVS ή το Subversion (πριν την έκδοση 1.5), στα οποία ο χρήστης που έκανε τη συγχώνευση έπρεπε ο ίδιος να βρει ποια πρότερη κατάσταση ήταν η καλύτερη δυνατή βάση. Αυτό κάνει τις συγχωνεύσεις στο Git πολύ ευκολότερες από ότι σε αυτά τα παλιότερα συστήματα.

Τώρα που η εργασία μας έχει συγχωνευτεί, δεν χρειάζόμαστε πλέον τον κλάδο iss53. Μπορούμε να κλείσουμε το ζήτημα στο σύστημα παρακολούθησης προβλημάτων μας και να διαγράψουμε τον κλάδο:

Ενίοτε, η διαδικασία συγχώνευσης δεν εξελισσεται τόσο ομαλά. Αν έχουμε τροποποιήσει το ίδιο σημείο του ίδιου αρχείου με διαφορετικό τρόπο στους δύο κλάδους που συγχωνεύουμε, το Git δεν θα μπορέσει να τους συγχωνεύσει καθαρά. Αν η λύση μας για το πρόβλημα #53 και η λύση μας για το επείγον πρόβλημα τροποποίησαν το ίδιο τμήμα ενός αρχείου, θα πάρουμε ένα μήνυμα σύγκρουσης συγχώνευσης περίπου σαν το παρακάτω:

Το Git δεν μπόρεσε να δημιουργήσει αυτόματα μία νέα υποβολή συγχώνευσης. Διέκοψε τη διαδικασία, ώστε να επιλύσουμε τη σύγκρουση. Αν θέλουμε να δούμε ποια αρχεία δεν έχουν συγχωνευτεί σε οποιοδήπτε σημείο μετά από μία σύγκρουση συγχώνευσης, τρέχουμε την εντολή git status:

Ο,τιδήποτε εμπλέκεται σε σύγκρουση συγχώνευσης και δεν έχει επιλυθεί καταγράφεται ως unmerged. Το Git προσθέτει τυποποιημένους σημειωτές “επίλυσης σύγκρουσης” στα αρχεία που εμπλέκονται σε συγκρούσεις, ώστε να τα ανοίξουμε ιδιοχείρως και να επιλύσουμε αυτές τις διαφορές. Το αρχείο μας θα περιέχει ένα τμήμα που θα φαίνεται κάπως έτσι:

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

Αυτή η επίλυση της σύγκρουσης περιέχει λίγο από κάθε τμήμα και οι γραμμές που περιέχουν τα <<<<<<<, ======= και >>>>>>> έχουν αφαιρεθεί εντελώς. Αφού έχουμε επιλύσει όλα τα τμήματα σε κάθε αρχείο που εμπλέκεται σε σύγκρουση, τρέχουμε git add σε καθένα από αυτά τα αρχεία, ώστε να επισημανθεί ως επιλυμένο. Η προσθήκη ενός αρχείου στο στάδιο καταχώρισης το επισημαίνει ως επιλυμένο.

Αν θέλουμε αν χρησιμοποιήσουμε κάποιο γραφικό εργαλείο για να επιλύσουμε αυτές τις συγκρούσεις, τρέξτε git mergetool για να εκκινήσουμε ένα κατάλληλο γραφικό εργαλείο συγχώνευσης που θα μας καθοδηγήσει ανάμεσα στις συγκρούσεις:

Αν θέλουμε να χρησιμοποιήσουμε κάποιο εργαλείο συγχώνευσης διαφορετικό από το προεπιλεγμένο (το Git έχει επιλέξει το opendiff σε αυτήν την περίπτωση, διότι η τρέξαμε την εντολή σε Mac), μπορούμε να δούμε όλα τα εργαλεία που υποστηρίζονται στο πάνω μέρος μετά από το one of the following tools: Απλά γράφουμε το όνομα του εργαλείου που θέλουμε να χρησιμοποιήσουμε.

Αφού βγούμε από το εργαλείο συγχώνευσης, το Git μάς ρωτάει αν η συγχώνευση ήταν επιτυχής. Αν του πούμε ότι ήταν, ωθεί το αρχείο στο στάδιο καταχώρισης ώστε να επισημανθεί ως επιλυμένο. Μπορούμε να τρέξουμε την εντολή git status ξανά για να επιβεβαιώσουμε ότι όλες οι συγκρούσεις έχουν επιλυθεί:

Αν είμαστε ευχαριστημένοι με το αποτέλεσμα και επιβεβαιώσουμε ότι όλα τα εμπλεκόμενα σε συγκρούσεις αρχεία έχουν ωθηθεί στο στάδιο καταχώρισης, μπορούμε να πληκτρολογήσουμε git commit για να οριστικοποιήσουμε την υποβολή συγχώνευσης. Το μήνυμα υποβολής είναι εκ προεπιλογής κάπως έτσι:

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