10.7 Εσωτερική λειτουργία του Git - Διατήρηση και ανάκτηση δεδομένων

Περιστασιακά, το Git εκτελεί αυτόματα μια εντολή που ονομάζεται auto gc. Τις περισσότερες φορές, αυτή η εντολή δεν κάνει τίποτα. Ωστόσο, αν υπάρχουν πάρα πολλά πακέτα (packfiles) ή πάρα πολλά χαλαρά αντικείμενα (αντικείμενα που δεν περιέχονται σε πακέτα), το Git εξαπολύει μια πλήρως εξοπλισμένη git gc. Το “gc” σημαίνει συλλογή σκουπιδιών (garbage collection) και η εντολή κάνει πολλά πράγματα: συγκεντρώνει όλα τα χαλαρά αντικείμενα και τα τοποθετεί σε πακέτα, ενοποιεί πακέτα σε ένα μεγάλο πακέτο και αφαιρεί αντικείμενα που δεν είναι προσπελάσιμα από καμία υποβολή και έχουν ηλικία λίγων μηνών.

Μπορούμε να εκτελέσουμε την auto gc αυτόματα ως εξής:

Επαναλαμβάνουμε ότι αυτή η εντολή γενικά δεν κάνει τίποτα. Πρέπει να έχουμε περίπου 7.000 χαλαρά αντικείμενα ή περισσότερα από 50 πακέτα ώστε το Git να εξαπολύσει μια πραγματική εντολή gc. Μπορούμε να τροποποιήσουμε αυτά τα όρια με τις ρυθμίσεις gc.auto και gc.autopacklimit αντίστοιχα.

Το άλλο πράγμα που θα κάνει η gc είναι να συσκευάσει τις αναφορές μας σε ένα μοναδικό αρχείο. Ας υποθέσουμε ότι το αποθετήριό μας περιέχει τους ακόλουθους κλάδους και ετικέτες:

Αν εκτελέσουμε την git gc, αυτά τα αρχεία δεν θα υπάρχουν πλέον στον κατάλογο refs. Το Git θα τα μετακινήσει για λόγους αποδοτικότητας σε ένα αρχείο με όνομα .git/packed-refs που μοιάζει με αυτό:

Εάν ενημερώσουμε μια αναφορά, το Git δεν επεξεργάζεται αυτό το αρχείο, αλλά γράφει ένα νέο αρχείο στον κατάλογο refs/heads. Για να πάρει τον κατάλληλο SHA-1 για μια δεδομένη αναφορά, το Git ελέγχει αυτήν την αναφορά στον κατάλογο refs και στη συνέχεια ελέγχει το αρχείο packed-refs ως εναλλακτική λύση. Ωστόσο, αν δεν μπορούμε να βρούμε μια αναφορά στον κατάλογο refs, πιθανότατα βρίσκεται στο αρχείο packed-refs.

Παρατηρούμε ότι η τελευταία γραμμή του αρχείου αρχίζει με ένα ^. Αυτό σημαίνει ότι η ετικέτα ακριβώς από πάνω είναι μια ετικέτα επισημειωμένη και ότι η γραμμή είναι η υποβολή στην οποία δείχνει η επισημειωμένη ετικέτα.

Όταν δουλεύουμε στο Git, κάποια στιγμή ενδέχεται να χάσουμε κάποια υποβολή κατά λάθος. Γενικά, αυτό συμβαίνει όταν επιβάλλουμε τη διαγραφή (force-delete) ενός κλάδου που είχε κάποια δουλειά που τελικά θέλαμε τον κλάδο· ή κάναμε hard-reset σε έναν κλάδο, εγκαταλείποντας έτσι υποβολές από τις οποίες θέλαμε κάτι. Αν υποθέσουμε ότι έχει συμβεί κάτι τέτοιο, τότε πώς μπορούμε να ανακτήσουμε τις υποβολές μας;

Ακολουθεί ένα παράδειγμα στο οποίο κάνουμε hard-reset στον κύριο κλάδο του αποθετηρίου μας σε μια παλαιότερη υποβολή και στη συνέχεια ανακτά τις χαμένες υποβολές. Αρχικά, ας θυμηθούμε πού βρίσκεται το αποθετήριό μας:

Τώρα, μετακινούμε τον κλάδο master πίσω στη μεσαία υποβολή:

Ουσιαστικά έχουμε χάσει τις δύο πρώτες υποβολές —δεν έχουμε κλάδο από τον οποίο οι υποβολές αυτές είναι προσπελάσιμες. Πρέπει να βρούμε τον τελευταίο SHA-1 και στη συνέχεια να προσθέσουμε έναν κλάδο που να δείχνει σε αυτόν. Το κόλπο είναι να βρούμε τον SHA-1 της τελευταίας υποβολης —δεν τον έχουμε απομνημονεύσει κιόλας, σωστά;

Συχνά, ο πιο γρήγορος τρόπος είναι να χρησιμοποιήσουμε ένα εργαλείο που ονομάζεται git reflog. Καθώς δουλεύουμε, το Git καταγράφει σιωπηλά ποιος είναι ο HEAD μας κάθε φορά που τον αλλάζουμε. Κάθε φορά που αλλάζουμε κλάδο ή υποβάλλουμε, το reflog ενημερώνεται. Το reflog ενημερώνεται επίσης από την εντολή git update-ref, που είναι ένας άλλος λόγος να τη χρησιμοποιήσουμε αντί να γράψουμε την τιμή SHA-1 στα αρχεία ref, όπως καλύψαμε στο Αναφορές του Git. Μπορούμε να δούμε πού ήμασταν ανά πάσα στιγμή εκτελώντας το git reflog:

Βλέπουμε τις δύο υποβολές που είχαμε ανακτήσει, ωστόσο δεν υπάρχουν πολλές πληροφορίες εδώ. Για να δούμε τις ίδιες πληροφορίες σε μία πολύ πιο χρήσιμη μορφή, μπορούμε να εκτελέσουμε την git log -g, η οποία θα μας δώσει μια κανονική έξοδο μητρώου για το reflog μας.

Φαίνεται ότι η υποβολή που χάσαμε είναι η κάτω υποβολή και μπορούμε να την ανακτήσουμε δημιουργώντας έναν νέο κλάδο σε αυτήν την υποβολή. Για παράδειγμα, μπορούμε να ξεκινήσουμε έναν κλάδο που ονομάζεται recover-branch σε αυτήν την υποβολή (ab1afef):

Μια ομορφιά! Τώρα έχουμε έναν κλάδο που ονομάζεται recover-branch που είναι αυτός στον οποίο βρισκόταν ο κλάδος master, καθιστώντας τις δύο πρώτες υποβολές προσπελάσιμες και πάλι. Στη συνέχεια, ας υποθέσουμε ότι η απώλειά μας για κάποιο λόγο δεν ήταν στο reflog —μπορούμε να προσομοιώσουμε κάτι τέτοιο διαγράφοντας τον κλάδο recover-branch και διαγράφοντας το reflog. Τώρα, οι δύο πρώτες υποβολές δεν είναι προσπελάσιμες από τίποτα:

Επειδή τα δεδομένα reflog αποθηκεύονται στον κατάλογο .git/logs/, ουσιαστικά δεν έχουμε κανένα reflog. Πώς μπορούμε να ανακτήσουμε αυτήν την υποβολή σε αυτό το σημείο; Ένας τρόπος είναι να χρησιμοποιήσουμε το βοηθητικό πρόγραμμα git fsck, το οποίο ελέγχει την ακεραιότητα της βάσης δεδομένων μας. Εάν το εκτελέσουμε με την επιλογή --full, θα εμφανιστούν όλα τα αντικείμενα στα οποία δεν δείχνει κανένα άλλο αντικείμενο:

Σε αυτήν την περίπτωση, μπορούμε να δούμε την υποβολή μας που λείπει μετά από τη συμβολοσειρά “dangling commit” (εκκρεμής υποβολή). Μπορούμε να την ανακτήσουμε με τον ίδιο τρόπο, προσθέτοντας έναν κλάδο που δείχνει σε αυτόν τον αριθμό SHA-1.

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

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

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

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

Ωχ! Δεν θέλουμε να προσθέσουμε ένα τεράστιο tarball στο έργο μας. Καλύτερα να το ξεφορτωθούμε:

Τώρα, κάνουμε gc στη βάση δεδομένων μας και βλέπουμε πόσο χώρο χρησιμοποιούμε:

Μπορούμε να εκτελέσουμε την εντολή count-objects για να δούμε γρήγορα πόσο χώρο χρησιμοποιούμε:

Η καταχώριση size-pack είναι το μέγεθος των πακέτων σε KB, επομένως χρησιμοποιούμε σχεδόν 5 MB. Πριν από την τελευταία υποβολή, χρησιμοποιούσαμε περίπου 2 ΚB —σαφώς, η κατάργηση του αρχείου από την προηγούμενη υποβολή δεν το κατήργησε από το ιστορικό μας. Κάθε φορά που κάποιος κλωνοποιεί αυτό το αποθετήριο, θα πρέπει να κλωνοποιήσει όλα τα 5MB μόνο για να πάρει αυτό το μικροσκοπικό έργο, επειδή προσθέσαμε κατά λάθος ένα μεγάλο αρχείο. Κάθε φορά που κάποιος κλωνοποιεί αυτό το αποθετήριο, θα πρέπει να κλωνοποιήσει και αυτά τα 5 MB μόνο για να πάρει αυτό το μικροσκοπικό έργο, επειδή προσθέσαμε κατά λάθος ένα μεγάλο αρχείο. Ας απαλλαγούμε από αυτό.

Πρώτα πρέπει να το βρούμε. Σε αυτήν την περίπτωση, ξέρουμε ήδη τι αρχείο είναι. Αλλά ας υποθέσουμε ότι δεν ξέρουμε· πώς θα προσδιορίζαμε ποιο αρχείο ή αρχεία καταλάμβαναν τόσο μεγάλο χώρο; Αν εκτελέσουμε την git gc, θα δούμε ότι όλα τα αντικείμενα βρίσκονται σε ένα πακέτο· μπορούμε να προσδιορίσουμε τα μεγάλα αντικείμενα, αν τρέξουμε μια άλλη εντολή διοχέτευσης που ονομάζεται git verify-pack και ταξινομήσουμε με βάση το τρίτο πεδίο στην έξοδο, που είναι το μέγεθος των αρχείων. Μπορούμε επίσης αυτήν την έξοδο να την παροχετεύσουμε στην εντολή tail, επειδή ενδιαφερόμαστε μόνο για τα τελευταία (τα μεγαλύτερα) αρχεία:

Το μεγάλο αντικείμενο βρίσκεται στο κάτω μέρος: 5 MB. Για να μάθουμε ποιο αρχείο είναι, θα χρησιμοποιήσουμε την εντολή rev-list, την οποία χρησιμοποιήσαμε για λίγο στο Επιβολή συγκεκριμένης μορφής μηνύματος υποβολής. Εάν περάσουμε την επιλογή --objects στην rev-list, εμφανίζονται αριθμοί SHA-1 όλων των υποβολών και όλων των blob με τις διαδρομές αρχείων που σχετίζονται με αυτά. Μπορούμε να χρησιμοποιήσουμε το παρακάτω για να βρούμε το όνομα του blob μας:

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

Πρέπει να ξαναγράψουμε όλες τις υποβολές downstream από την 7b30847 για να καταργήσουμε πλήρως αυτό το αρχείο από το ιστορικό του Git. Για να το κάνουμε αυτό, χρησιμοποιούμε την filter-branch, την οποία χρησιμοποιήσαμε και στην ενότητα Η ιστορία ξαναγράφεται:

Η επιλογή --index-filter είναι παρόμοια με την επιλογή --tree-filter που χρησιμοποιείται και στην ενότητα Η ιστορία ξαναγράφεται με την εξαίρεση ότι αντί να περάσουμε μια εντολή που τροποποιεί τα αρχεία που έχουν ενημερωθεί (checkout) στον δίσκο, τροποποιούμε το στάδιο καταχώρισης ή ευρετήριο κάθε φορά.

Αντί να διαγράψουμε ένα συγκεκριμένο αρχείο χρησιμοποιώντας π.χ. την rm file, θα πρέπει να το διαγράψουμε με την git rm --cached —πρέπει να το αφαιρέσουμε από το ευρετήριο, όχι από τον δίσκο. Αυτό το κάνουμε για μεγαλύτερη ταχύτητα— επειδή το Git δεν χρειάζεται να κάνει ενημερώσει (checkout) κάθε αναθεώρηση στον δίσκο προτού εκτελέσει το φίλτρο μας, η διαδικασία μπορεί να είναι πολύ, πολύ γρηγορότερη. Μπορούμε να ολοκληρώσουμε την ίδια εργασία με --tree-filter, αν το θέλουμε. Η επιλογή --ignore-unmatch στην git rm της λέει να μην τερματίσει με σφάλμα αν το μοτίβο που προσπαθούμε να καταργήσουμε δεν υπάρχει. Τέλος, ζητάμε από τη filter-branch να ξαναγράψει το ιστορικό μας μόνο από την υποβολή 7b30847, επειδή ξέρουμε ότι από αυτήν ξεκίνησε το συγκεκριμένο πρόβλημα. Διαφορετικά, θα ξεκινήσει από την αρχή και η διαδικασία θα διαρκέσει περισσότερο χωρίς λόγο.

Το ιστορικό μας δεν περιέχει πλέον καμία αναφορά στο συγκεκριμένο αρχείο. Ωστόσο, το reflog μας και ένα νέο σύνολο αναφορών που πρόσθεσε το Git όταν τρέξαμε τη filter-branch κάτω από το .git/refs/original εξακολουθούν να έχουν, οπότε θα πρέπει να τις αφαιρέσουμε και στη συνέχεια να ξαναπακετάρουμε τη βάση δεδομένων. Πρέπει να απαλλαγούμε από ο,τιδήποτε έχει δείκτη σε αυτές τις παλιές υποβολές πριν να ξαναπακετάρουμε:

Ας δούμε πόσο χώρο έχουμε γλιτώσει.

Το μέγεθος του αποθηκευμένου αποθετηρίου είναι κάτω από 8K, το οποίο είναι πολύ καλύτερο από τα 5 MB. Μπορούμε να δούμε από την τιμή size ότι το μεγάλο αντικείμενο βρίσκεται ακόμα στα χαλαρά αντικείμενά μας, άρα δεν έχει διαγραφεί· αλλά δεν θα μεταφερθεί σε κάποια ώθηση ή σε επόμενη κλωνοποίηση, κάτι που είναι σημαντικό. Εάν το θέλαμε πραγματικά, θα μπορούσαμε να διαγράψουμε το αντικείμενο εντελώς τρέχοντας git prune με την επιλογή --expire: