7.7 Εργαλεία του Git - Απομυθοποίηση της reset

Ένας ευκολότερος τρόπος για να σκεφτούμε τα reset και checkout είναι μέσα από ένα νοητική πλαίσιο στο οποίο το Git είναι διαχειριστής του περιεχομένου τριών διαφορετικών δέντρων. Με τον όρο “δέντρο” εδώ εννοούμε ουσιαστικά “συλλογή αρχείων”, όχι ειδικότερα τη δομή δεδομένων. (Υπάρχουν μερικές περιπτώσεις στις οποίες το Ευρετήριο δεν λειτουργεί ακριβώς όπως ένα δέντρο, αλλά για τον σκοπό μας είναι ευκολότερο να το σκεφτούμε με αυτόν τον τρόπο προς το παρόν.)

Το Git, ως σύστημα, διαχειρίζεται και μεταχειρίζεται τρία δέντρα στην κανονική του λειτουργία:

Ο κύριος σκοπός του Git είναι να καταγράφει στιγμιότυπα του έργου μας σε διαδοχικά καλύτερες καταστάσεις, χειριζόμενο αυτά τα τρία δέντρα.

Ας οπτικοποιήσουμε αυτήν τη διαδικασία: ας πούμε ότι πηγαίνουμε σε έναν νέο κατάλογο με μόνον ένα αρχείο σε αυτόν. Θα ονομάσουμε αυτήν την έκδοση του αρχείου v1 και θα το απεικονίζουμε με μπλε χρώμα. Τώρα τρέχουμε την git init, η οποία θα δημιουργήσει ένα αποθετήριο Git με μια αναφορά HEAD που δείχνει σε έναν κλάδο που δεν υπάρχει (ο master δεν υπάρχει ακόμα).

Σε αυτό το σημείο, μόνο το δέντρο του Καταλόγου Εργασίας έχει κάποιο περιεχόμενο.

Τώρα θέλουμε να υποβάλουμε αυτό το αρχείο, οπότε χρησιμοποιούμε την git add για να πάρουμε το περιεχόμενο που βρίσκεται στον Κατάλογο Εργασίας και να το αντιγράψουμε στο Ευρετήριο.

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

Αν εκτελέσουμε την git status, δεν θα δούμε αλλαγές, αφού και τα τρία δέντρα είναι τα ίδια.

Τώρα θέλουμε να κάνουμε μια αλλαγή σε αυτό το αρχείο και να την υποβάλλουμε. Θα επαναληφθεί η ίδια διαδικασία· πρώτα αλλάζουμε το αρχείο στον Κατάλογο Εργασίας μας. Ας ονομάσουμε αυτην την έκδοση του αρχείου v2 και θα την απεικονίζουμε με κόκκινο χρώμα.

Αν εκτελέσουμε την εντολή git status τώρα, το αρχείο θα εμφανιστεί με κόκκινο χρώμα με την ένδειξη “Changes not staged for commit”, επειδή αυτή η εγγραφή διαφέρει μεταξύ του Ευρετηρίου και του Καταλόγου Εργασίας. Στη συνέχεια τρέχουμε την git add σε αυτό για να το προσθέσουμε στο Ευρετήριο μας.

Σε αυτό το σημείο, αν εκτελέσουμε την git status θα δούμε το αρχείο πράσινο κάτω από την ένδειξη Changes to be committed επειδή το Ευρετήριο και ο HEAD διαφέρουν —δηλαδή, η προτεινόμενη επόμενη υποβολή μας τώρα είναι διαφορετική από την τελευταία μας υποβολή. Τέλος, τρέχουμε git commit για να οριστικοποιήσουμε την υποβολή.

Τώρα η git status δεν θα μας δώσει καμία έξοδο, αφού και τα τρία δέντρα είναι τα ίδια ξανά.

Όταν μεταβαίνουμε από έναν κλάδο σε άλλον ή κλωνοποιούμε, γίνεται μία παρόμοια διαδικασία. Όταν μεταβαίνουμε σε έναν κλάδο, αλλάζει ο HEAD ώστε να δείχνει στο ref του νέου κλάδου, το Ευρετήριο γεμίζει με το στιγμιότυπο αυτής της υποβολής και στη συνέχεια τα περιεχόμενα του Ευρετηρίου αντιγράφουνται στον Κατάλογο Εργασίας.

Η εντολή reset γίνεται κατανοητή πιο εύκολα στο παρακάτω πλαίσιο. Για τους σκοπούς αυτών των παραδειγμάτων, ας πούμε ότι τροποποιήσαμε ξανά το file.txt και το υποβάλαμε για τρίτη φορά. Έτσι τώρα το ιστορικό μας μοιάζει με αυτό:

Ας δούμε τώρα τι ακριβώς κάνει η reset όταν την καλούμε. Χειραγωγεί άμεσα αυτά τα τρία δέντρα με έναν απλό και προβλέψιμο τρόπο. Κάνει το πολύ μέχρι τρεις βασικές λειτουργίες.

Τα προηγούμενα καλύπτουν τη συμπεριφορά της reset στη βασική της μορφή, αλλά μπορούμε επίσης να της παράσχουμε μία διαδρομή στην οποία να δράσει. Αν καθορίσουμε μια διαδρομή, η reset θα παραλείψει το Βήμα 1 και θα περιορίσει το υπόλοιπο των ενεργειών της σε ένα συγκεκριμένο αρχείο ή σύνολο αρχείων. Αυτό πραγματικά έχει μία λογική —ο HEAD είναι απλώς ένας δείκτης και δεν μπορεί να δείχνει σε ένα τμήμα μίας υποβολής και σε ένα τμήμα μίας άλλης. Αλλά το Ευρετήριο και ο Κατάλογος Εργασίας μπορούν να ενημερώνονται εν μέρει, οπότε η reset συνεχίζει με τα Bήματα 2 και 3.

Ας υποθέσουμε, λοιπόν, ότι τρέχουμε την git reset file.txt. Αυτή η φόρμα (αφού δεν έχουμε καθορίσει τον αριθμό SHA-1 μιας υποβολής ή έναν κλάδο και δεν έχουμε ορίσει --soft ή --hard) είναι συντομογραφία της git reset --mixed HEAD file.txt, η οποίο θα:

Έτσι, ουσιαστικά απλά αντιγράφει το file.txt από τον HEAD στο Ευρετήριο.

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

Αυτός είναι ο λόγος για τον οποίο η έξοδος της εντολής git status υπονοεί ότι την εκτελούμε για να αφαιρέσουμε ένα αρχείο από το στάδιο καταχώρισης. (Περισσότερα σχετικά με αυτό υπάρχουν στην ενότητα Αφαίρεση αρχείου από το στάδιο καταχώρισης.)

Θα μπορούσαμε εξίσου εύκολα να μην αφήσουμε τον Git να υποθέσει ότι εννοούσαμε “έλξε τα δεδομένα από τον HEAD”, καθορίζοντας μια συγκεκριμένη υποβολή από την οποία θέλαμε αν έλξουμε αυτήν την έκδοση του αρχείου. Απλά θα έπρεπε να τρέξουμε κάτι σαν την git reset eb43bf file.txt.

Αυτό ουσιαστικά κάνει το ίδιο πράγμα με το να είχαμε επαναφέρει το περιεχόμενο του αρχείου στη v1 στον Κατάλογο Εργασίας, να τρέξουμε git add σε αυτό και στη συνέχεια να το επαναφέρουμε ξανά στην v3 (χωρίς στην πραγματικότητα να περάσουμε όλα αυτά τα στάδια). Αν εκτελέσουμε τώρα την git commit, θα καταγράψει μια αλλαγή που θα επαναφέρει αυτό το αρχείο πίσω στην v1, παρόλο που στην πραγματικότητα ποτέ δεν το ξαναείχαμε στον Κατάλογο Εργασίας .

Είναι επίσης ενδιαφέρον να σημειώσουμε ότι όπως και η git add, η εντολή reset θα δέχεται μια επιλογή --patch για την αφαίρεση από το στάδιο καταχώρισης περιεχομένου κομμάτι-κομμάτι. Επομένως, μπορούμε να αφαιρέσουμε από το στάδιο καταχώρισης ή να επαναφέρουμε περιεχόμενο, επιλεκτικά. ert content.

Ας δούμε πώς να κάνουμε κάτι ενδιαφέρον με αυτήν τη νέα δύναμη —τη συναρμογή υποβολών.

Ας πούμε ότι έχουμε μια σειρά υποβολών με μηνύματα όπως oops., WIP και forgot this file. Μπορούμε να χρησιμοποιήσουμε την reset για να τα συναρμόσουμε γρήγορα και εύκολα σε μια ενιαία υποβολή που μας κάνει να φανούμε πραγματικά έξυπνοι. (Στην ενότητα Squashing Commits υπάρχει ένας άλλος τρόπος για να το κάνουμε αυτό, αλλά σε αυτό το παράδειγμα θα χρησιμοποιήσουμε τη reset επειδή είναι απλούστερο.)

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

Μπορούμε να εκτελέσουμε την git reset --soft HEAD~2 για να μετακινήσουμε τον κλάδο HEAD πίσω σε μια παλαιότερη υποβολή (την πρώτη υποβολή που θέλουμε να κρατήσουμε):

Στη συνέχεια εκτελούμε ξανά την git commit:

Τώρα μπορούμε να δούμε ότι το προσβάσιμο ιστορικό μας, δηλαδή το ιστορικό που θα ωθήσουμε, τώρα μοιάζει σαν να είχαμε μία υποβολή με το αρχείο file-a.txt (v1), και στη συνέχεια μία δεύτερη που τροποποίησε το file-a.txt στο v3 και πρόσθεσε το file-b.txt. Η υποβολη με την έκδοση v2 του αρχείου δεν βρίσκεται πλέον στο ιστορικό.

Τέλος, θα μπορούσε να αναρωτηθεί κανείς ποια είναι η διαφορά ανάμεσα στις checkout και reset. Όπως η reset, έτσι και η checkout χειρίζεται τα τρία δέντρα και είναι λίγο διαφορετική ανάλογα με το αν της δίνουμε και μια διαδρομή αρχείου ή όχι.

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

Ακολουθεί ένα σκονάκι σχετικά με το ποιες εντολές επηρεάζουν ποια δέντρα. Η στήλη HEAD γίνεται REF αν αυτή η εντολή μετακινεί την αναφορά (κλάδο) στην οποία δείχνει ο HEAD και HEAD αν μετακινεί τον ίδιο τον HEAD. Ιδιαίτερη προσοχή χρειάζεται η στήλη “Ασφαλής για ΚΕ;” —αν αναφέρει ΟΧΙ, τότε πρέπει να ξανασκεφτούμε αν πραγματικά θέλουμε να εκτελέσουμε αυτήν την εντολή.