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

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

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

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

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

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

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

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

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

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

Σε αυτή τη συγχώνευση υπάρχει η έκφραση “fast-forward”. Επειδή η υποβολή C4 στον οποίο έδειχνε ο κλάδος hotfix τον οποίο συγχωνεύσαμε ήταν ακριβώς μπροστά από την υποβολή C2 στην οποία είμαστε, το 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) και έχει την ιδιαιτερότητα ότι έχει περισσότερους από έναν γονείς.

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

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

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

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

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

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

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

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

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

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

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