Το προφίλ μας στο Google Plus
2

VCS και Git: Τι στο καλό είναι και γιατί πρέπει να νοιαστείτε

Στον κόσμο των Version Control Systems το Git έχει φέρει τα πάνω κάτω, ωστόσο επτά περίπου από εσάς δεν έχετε ιδέα για το τι γράψαμε μόλις. Αλλά μην ανησυχείτε. Η παρούσα μίνι σειρά άρθρων ετοιμάστηκε για εσάς, τους επτά. Οι υπόλοιποι μπορείτε να την αγνοήσετε με ασφάλεια. Διαβάστε αν είναι κάποιο άλλο από τα άρθρα του τεύχους ή ένα άρθρο από άλλο τεύχος. Εδώ δεν έχει κάτι για εσάς. Αλήθεια σας λέμε.

Η διαχείριση των τροποποιήσεων σε έγγραφα, δικτυακούς τόπους, προγράμματα κ.λπ. αναφέρεται ως version control (έλεγχος εκδόσεων) ή revision control (έλεγχος αναθεωρήσεων) ή αλλιώς source control (έλεγχος πηγαίου κώδικα). Παραδοσιακά, οι αλλαγές αντικατοπτρίζονται από έναν αριθμό ή/και ένα γράμμα και σε κάθε μία από αυτές αντιστοιχίζεται ένα timestamp.

Για παράδειγμα, ένας υπάλληλος εταιρείας που προετοιμάζει μια αναφορά προόδου για το τρίμηνο που πέρασε, ξεκινά μ’ ένα έγγραφο το οποίο αρχικά ονομάζει report-r1.doc. Μετά από μία εβδομάδα, αφού έχει συγκεντρώσει αρκετά στοιχεία από συνεργάτες, ίσως έχει φτάσει στο report-r4.doc. Επειδή δεν είναι σίγουρος για το πόσο κοντά βρίσκεται στην τελική αναφορά (ίσως αφήσει εκτός συγκεκριμένους πίνακες ή γραφήματα), έχει κρατήσει και τα έγγραφα report-r2.doc και report-r3.doc. Κάποια στιγμή φτάνει στο report-r5.doc και του αρέσει. Πριν όμως στείλει την αναφορά στη Διεύθυνση, σκέφτεται ότι καλό είναι να τη δει και κάποιος που γνωρίζει καλύτερα γραμματική και συντακτικό. Εντάξει, για το τεχνικό μέρος δεν έχει κάποια αμφιβολία, όμως κρίμα είναι να ρεζιλευτεί με κανένα “ανεξαρτήτου ηλικίας” ή “εκ των ουκ άνευ”. Ειδοποιεί λοιπόν την κα Διορθώτρια (TM) από το GrammarNazis department κι αμέσως της στέλνει το report-r5.doc. Όπως αναμενόταν, εκείνη εντοπίζει αρκετά τραγικά λάθη. Τα διορθώνει ξεφυσώντας και του επιστρέφει τη νέα εκδοχή της αναφοράς, ονόματι report-r5d.doc (“d”, από το “dior8wmeno”: για κάποιο μυστήριο λόγο, στο GrammarNazis department χρησιμοποιούν greeklish στα ονόματα των αρχείων). Ο φίλος μας ρίχνει μια γρήγορη ματιά στο νέο έγγραφο και πραγματικά δεν καταλαβαίνει τι ακριβώς “διόρθωσε” (κάνει air-quotes) η κα Διορθώτρια (TM). Κρατάει ωστόσο το report-r5d.doc –ποτέ δεν ξέρεις– και στο τέλος προσθέτει μια ακόμα παράγραφο, η οποία πιστεύει ότι θα κάνει τη διαφορά. Το τελικό έγγραφο το ονομάζει report-r5-final.doc, στη Διεύθυνση όμως στέλνει ένα αντίγραφό του που ονομάζει Q1report.doc. Όλα καλά.

Στο προηγούμενο παράδειγμα, τα γράμματα και οι αριθμοί στα ονόματα των αρχείων βοηθούν το συντάκτη της αναφοράς να ολοκληρώσει ομαλά την εργασία του. Ακόμη και μετά από μήνες, αν ρίξει μια ματιά στα αρχεία report-r1, …, report-r5, report-r5d, report-r5d-final και Q1report, μάλλον θα θυμηθεί εύκολα σε τι αφορούν. Όταν μάλιστα φτάσει η ώρα για άλλη μια αναφορά, ίσως δεν τη ξεκινήσει από την αρχή αλλά από κάποιο εξ αυτών των αρχείων.

Γιατί VCS;
Σε σχετικά μικρά κι απλά πρότζεκτ, όπου έχουμε έναν μόνον εργαζόμενο ή έστω μια μικρή ομάδα ανθρώπων που συνεργάζονται, η διαχείριση των αλλαγών καθ’ όλη τη διάρκεια του έργου είναι πράγματι δυνατό να διευκολύνεται μόνο με την κατάλληλη ονομασία ενός συνόλου αρχείων, τα οποία μεταβάλλονται. Η κατάσταση όμως αλλάζει δραματικά όταν μιλάμε για πιο περίπλοκα ή/και πιο μεγάλα πρότζεκτ, μάλιστα ασχέτως αν έχουμε έναν εργαζόμενο ή περισσότερους. Χρειαζόμαστε τότε ένα σύγχρονο Version Control System (VCS) και στη συνέχεια παραθέτουμε μερικούς λόγους που συνηγορούν υπέρ της χρήσης του.

  • Αναπτύσσετε μια εφαρμογή *μόνος σας* και ήδη έχετε γράψει αρκετό κώδικα, πιθανώς σε περισσότερα από ένα αρχεία. Ξαφνικά θέλετε να δοκιμάσετε μια νέα ιδέα που μόλις σκεφτήκατε. Θα ήταν βολικό αν μπορούσατε να ξεκινήσετε εύκολα ένα νέο branch, δηλαδή ένα νέο πρότζεκτ με βάση το υπάρχον, στο οποίο θα μπορέσετε με ασφάλεια να δοκιμάσετε τη νέα σας ιδέα. Φυσικά, όταν μιλάμε για νέο πρότζεκτ δεν εννοούμε ότι ξεκινάτε από την αρχή. Αντίθετα, συνεχίζετε από το σημείο στο οποίο ήδη βρίσκεται το πρότζεκτ σας αλλά τώρα έχετε κι ένα δεύτερο πρότζεκτ που εξελίσσεται προς μια νέα κατεύθυνση. Τα αρχεία του παλιού πρότζεκτ μένουν ως έχουν και μάλιστα μπορείτε να δουλεύετε στο πρωτότυπο πρότζεκτ παράλληλα με το νέο — ας το πούμε πειραματικό.
  • Σε περίπτωση που η ιδέα σας αποδειχθεί καλή κι επιφέρει καρπούς, θα ήταν ευχής έργο αν μπορούσατε να συγχωνεύσετε (merge) με ακρίβεια τις όποιες αλλαγές στο αρχικό πρότζεκτ.
  • Αν πάλι η ιδέα σας αποδειχθεί αδιέξοδη, θα ήταν επίσης ευχής έργο αν επιστρέφατε στο αρχικό πρότζεκτ ξεχνώντας παντελώς το νέο branch. Εντάξει, αυτό γίνεται εύκολα, αρκεί, π.χ., να χρησιμοποιήσετε δύο κατάλληλα ονομασμένους καταλόγους, αλλά χρειάζεται προσοχή διότι πάντα υπάρχει το περιθώριο για σοβαρό λάθος. Για παράδειγμα, δεν είναι καθόλου απίθανο να ξεχάσετε σε ποιον κατάλογο βρίσκεστε και να τροποποιήσετε ή ακόμη και να διαγράψετε τα λάθος αρχεία.
  • Ας δούμε τώρα και την περίπτωση κατά την οποία *περισσότεροι από ένας* άνθρωποι δουλεύουν και συνεργάζονται πάνω στο ίδιο πρότζεκτ, κι επιθυμούν να έχουν μια σταθερή βάση αναφοράς (κύριο branch). Φυσικά, καθένας τους θα θέλει να δουλεύει στο δικό του branch κι όποτε χρειάζεται να συγχωνεύει τις αλλαγές στο κύριο.
  • Επιπρόσθετα, σκεφτείτε ότι οι συνεργάτες είναι πιθανό να μη βρίσκονται στον ίδιο χώρο εργασίας. Δεν αποκλείεται μάλιστα να έχουν διαφορετικά ωράρια ή ακόμη και να βρίσκονται σε διαφορετικές ζώνες ώρας. Πώς γίνεται να συνεννοούνται όλοι αποτελεσματικά, ώστε η εξέλιξη του πρότζεκτ να προχωρά χωρίς προβλήματα; Χρειάζεται άραγε να συνεννοούνται πριν κάνουν οτιδήποτε ή μήπως το πρότζεκτ θα μπορούσε να προχωρά χωρίς να έρχονται διαρκώς οδηγίες από τα “κεντρικά”;
    Ασχέτως της όποιας κεντρικής καθοδήγησης ή της παντελούς απουσίας της, όσοι εργάζονται σε μεγάλα πρότζεκτ είναι καλό να γνωρίζουν –ανά πάσα στιγμή– ποιος συνεργάτης εισήγαγε ποιες αλλαγές στο κύριο branch. Και είναι καλό να το γνωρίζουν χωρίς να επικοινωνούν μεταξύ τους.

Ζητήματα ή και προβλήματα σαν τα προηγούμενα, αντιμετωπίζονται με χρήση του κατάλληλου VCS. Κατ’ ελάχιστον, ένα σύστημα ελέγχου εκδόσεων καταγράφει τις αλλαγές που γίνονται σε ένα αρχείο ή σε ένα σύνολο αρχείων, κι επιτρέπει τη μετάβαση από έκδοση σε έκδοση. Αν και τα VCS χρησιμοποιούνται εκτεταμένα σε πρότζεκτ ανάπτυξης λογισμικού, όπου εκεί αυτό που αλλάζει είναι τα αρχεία με πηγαίο κώδικα, είναι κατάλληλα και για άλλους τύπους αρχείων. Έτσι, τα VCS επιστρατεύονται στην πράξη από γραφίστες, συγγραφείς, bloggers, παραγωγούς περιεχομένου κ.ά. Χάρη στα VCS, λοιπόν, είμαστε σε θέση να επαναφέρουμε προηγούμενες εκδόσεις ενός αρχείου ή ολόκληρου του πρότζεκτ, να βλέπουμε τις αλλαγές που συμβαίνουν με το πέρασμα του χρόνου, να γνωρίζουμε ποιος τροποποίησε τι, ποιος εντόπισε πρόβλημα και το ανέφερε κ.ο.κ. Αξίζει να υπογραμμιστεί η δυνατότητα των VCS για ανάκτηση προηγούμενων εκδόσεων: Χάρη σ’ αυτή, ακόμη κι αν φέρουμε τα πάνω κάτω και μπερδέψουμε τα πάντα σε απελπιστικό βαθμό, πολύ εύκολα μπορούμε να γυρίσουμε σε μια προηγούμενη, καλή κατάσταση.

Μερικά συστήματα ελέγχου εκδόσεων
Ένα από τα μακροβιότερα VCS είναι το λεγόμενο RCS (Revision Control System). Κυκλοφόρησε το 1982 και είναι ικανό να παρακολουθεί μεμονωμένα αρχεία αλλά όχι ολόκληρα πρότζεκτ. Ακόμη και σήμερα πάντως το RCS εξακολουθεί να είναι χρήσιμο, ειδικά σε σενάρια όπου έχουμε έναν μόνο χρήστη. Για παράδειγμα, ο διαχειριστής ενός server πιθανώς να καταφύγει στο RCS προκειμένου να διατηρεί διαφορετικές εκδόσεις μεμονωμένων configuration files ή scripts.

Εξέλιξη του RCS αποτελεί το CVS (Concurrent Versioning System). Το CVS κυκλοφόρησε πρώτη φορά το 1990, είναι ικανό να χειρίζεται ολόκληρα πρότζεκτ, ακολουθεί τη λογική client-server και υποστηρίζει περισσότερους από έναν χρήστες. Στον κόσμο του CVS, όλα τα αρχεία ενός πρότζεκτ, μαζί με τις διάφορες εκδόσεις και το ιστορικό της εξέλιξης του έργου, τηρούνται σε έναν κεντρικό server. Οι χρήστες (clients) συνδέονται στον server προκειμένου να πάρουν (check out) στους υπολογιστές τους ένα πλήρες αντίγραφο του πρότζεκτ. Ο καθένας τους εργάζεται πάνω στο τοπικό αντίγραφό του και μετά στέλνει (check in) στον server τις αλλαγές που πραγματοποίησε. Προκειμένου να αποφεύγεται το φαινόμενο των συγκρούσεων (conflicts), ο CVS server δέχεται αλλαγές μόνο για την πλέον πρόσφατη έκδοση ενός οποιουδήποτε αρχείου. Αυτό σημαίνει ότι οι χρήστες ανά πάσα στιγμή οφείλουν να έχουν ενημερωμένο το τοπικό τους αντίγραφο, εφαρμόζοντας τα patches όλων των άλλων χρηστών. Ο CVS client φροντίζει ώστε η ενημέρωση να γίνεται αυτόματα. Όταν όμως προκύπτουν συγκρούσεις μεταξύ μιας checked in αλλαγής και μιας τοπικής αλλαγής, τότε ζητείται η παρέμβαση του χρήστη.

Το δε Apache Subversion (SVN), εξάλλου, είναι σχεδιασμένο ως η βελτίωση του CVS και είναι συμβατό μ’ αυτό. Κυκλοφόρησε το 2000, χαίρει ευρείας αποδοχής σε κοινότητες ανοικτού κι ελεύθερου λογισμικού και χρησιμοποιείται σε πρότζεκτ όπως το FreeBSD, η Free Pascal κι ο GCC.

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

Revision. Αναφέρεται στη λεγόμενη αναθεώρηση ή αλλιώς στην έκδοση (version) ενός μεμονωμένου αρχείου ή ενός ολόκληρου πρότζεκτ. Κάθε μεταβολή που παγιώνεται, οδηγεί σε μια νέα έκδοση.

Baseline. Πρόκειται για μια εγκεκριμένη έκδοση, από την οποία ενδέχεται ν’ ακολουθήσουν κι άλλες εκδόσεις. Το baseline μπορούμε να το φανταζόμαστε ως σημείο ή ως βάση αναφοράς. Κατά περίπτωση, αντί για το baseline χρησιμοποιείται ένας από τους όρους label ή tag. Ένα baseline/label/tag ορίζει ένα snapshot. Σε κάθε πρότζεκτ, ορισμένα snapshots θεωρούνται πιο σημαντικά από άλλα. Αυτά τα ξεχωριστής σημασίας snapshots ενδέχεται να αντιστοιχούν σε δημοσιευμένες εκδόσεις (published releases) ή σε ορόσημα (milestones).

Branch. Ένα σύνολο αρχείων τα οποία υπόκεινται σε κάποιο VCS, ανά πάσα στιγμή είναι δυνατόν να “διακλαδωθεί” (branched). Αμέσως μετά τη διακλάδωση έχουμε δύο σύνολα αρχείων (baseline και branch) με το καθένα εξ αυτών να ακολουθεί το δικό του μονοπάτι. Από κάθε άποψη, τα δύο αυτά μονοπάτια είναι ανεξάρτητα. Ένα από τα δύο ίσως εξελίσσεται (για την ακρίβεια μεταβάλλεται), ενώ το άλλο ίσως παραμένει στάσιμο. Ίσως πάλι να εξελίσσονται και τα δύο, αλλά το καθένα με διαφορετικό ρυθμό.

Trunk. Έτσι ονομάζεται η μοναδική γραμμή εξέλιξης ενός πρότζεκτ η οποία δεν αποτελεί branch. Κατά περιπτώσεις, το trunk (κορμός) ονομάζεται mainline ή master.

Change. Μία αλλαγή (change ή diff ή delta) αναπαριστά μια συγκεκριμένη τροποποίηση σε κάποιο αρχείο, το οποίο παρακολουθείται από ένα VCS. Ο βαθμός διακριτικότητας (granularity) που πρέπει να έχει μια αλλαγή ώστε να θεωρηθεί ως τέτοια, εξαρτάται από το εκάστοτε VCS.

Repository. Το αποθετήριο (repository ή depot) είναι το μέρος όπου βρίσκονται τα αρχεία ενός πρότζεκτ, μαζί με όλα τα μεταδεδομένα (metadata) που δείχνουν την έως τώρα εξέλιξή του. Το αποθετήριο συνήθως βρίσκεται σε κάποιον server, ενδέχεται ωστόσο να είναι και τοπικό. Όταν μιλάμε για αρχικοποίηση (initialization) εννοούμε τη δημιουργία ενός νέου, κενού αποθετηρίου.

Checkout. Έτσι ονομάζεται η ενέργεια της δημιουργίας ενός τοπικού αντιγράφου των αρχείων ενός αποθετηρίου. Σημειώστε ότι έχουμε δυνατότητα λήψης συγκεκριμένης έκδοσης ή απλά της πλέον πρόσφατης.

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

Commit. Η αντίθετη ενέργεια του checkout είναι το commit (παράδοση) ή αλλιώς checkin. Αφού κάνουμε τις αλλαγές μας στο τοπικό αντίγραφο, με τη διαδικασία του commit τις ενσωματώνουμε (merge) στο κεντρικό αποθετήριο.

Conflict. Όταν δύο ή περισσότεροι χρήστες επιχειρούν να εισάγουν αλλαγές στο ίδιο αρχείο αλλά το VCS αδυνατεί να τις συμβιβάσει, τότε έχουμε το λεγόμενο conflict (σύγκρουση). Σε τέτοιες περιπτώσεις απαιτείται παρέμβαση από πλευράς κάποιου χρήστη, ο οποίος είτε θα ενσωματώσει όλες τις αλλαγές όπως κρίνει καλύτερα είτε θα επιλέξει μερικές αλλαγές και θ’ απορρίψει κάποιες άλλες.

Head. Η λεγόμενη κεφαλή συχνά αναφέρεται κι ως tip (κορυφή) και πάντα “δείχνει” το πλέον πρόσφατο commit, είτε στο trunk είτε σε κάποιο branch. Το trunk και κάθε branch έχουν το δικό τους head, σε ορισμένες περιπτώσεις ωστόσο η κεφαλή του trunk γράφεται με κεφαλαία (HEAD).

Update. Με την ενημέρωση (update) επικαιροποιούμε το τοπικό μας αντίγραφο με όλες τις αλλαγές που έχουν συμβεί στο αποθετήριο από άλλους χρήστες.

Κατανεμημένα VCS
Τα συγκεντρωτικά (centralized) VCS, όπως, π.χ., είναι τα CVS και Subversion, επιτρέπουν σε ομάδες χρηστών να συνεργάζονται ομαλά πάνω στο ίδιο πρότζεκτ. Από τη στιγμή που ο καθένας κάνει τακτικά commits ή/και updates, όλοι είναι σε θέση να γνωρίζουν ποιος εργάζεται πάνω σε τι, ενώ βεβαίως όλοι μπορούν και παρακολουθούν την πορεία του πρότζεκτ. Την ίδια στιγμή, ο διαχειριστής του κεντρικού server ελέγχει τα δικαιώματα κάθε χρήστη κι αποφασίζει για την εξέλιξη του πρότζεκτ. Τα centralized VCS όμως έχουν και μειονεκτήματα. Ένα από τα σοβαρότερα είναι η απουσία ευελιξίας από μέρους τους, εν όψει προσωρινής βλάβης ή κατάρρευσης. Σκεφτείτε, π.χ., ότι ο κεντρικός server ενός VCS για κάποιο λόγο πέφτει. Μέχρι να είναι και πάλι πλήρως λειτουργικός και διαθέσιμος, κανείς δεν μπορεί να κάνει updates ή commits, ούτε φυσικά να συνεργαστεί με άλλους. Ακόμα χειρότερα, αν ο δίσκος του server χαλάσει και δεν υπάρχει backup, όλο το πρότζεκτ χάνεται και δεν υπάρχει δυνατότητα πλήρους ανακατασκευής του από τα όποια τοπικά αντίγραφα.

Το σοβαρό αυτό μειονέκτημα των συγκεντρωτικών VCS έρχονται ν’ αντισταθμίσουν τα κατανεμημένα VCS (Distributed Version Control Systems). Δύο παραδείγματα κατανεμημένων VCS αποτελούν τα Git και Mercurial. Σε καθένα απ’ αυτά, οι χρήστες δεν κάνουν checkout μόνο το πλέον πρόσφατο snapshot του πρότζεκτ. Πολύ περισσότερο, κλωνοποιούν ολόκληρο το αποθετήριο. Ακόμη λοιπόν κι αν ο server τιναχτεί στον αέρα με μανία κι όταν προσγειωθεί γίνει κομματάκια και δεν υπάρχει ούτε δείγμα backup, ξεκινώντας από έναν οποιονδήποτε πελάτη-κλώνο θα είναι δυνατό να ανακατασκευάσουμε το αποθετήριο.

Η γέννηση του Git
Ένα από τα μεγαλύτερα γνωστά πρότζεκτ Ανοικτού Λογισμικού είναι ο πυρήνας του Linux. Από την πρώτη του έκδοση (0.0.1, ο Linus Torvalds την κυκλοφόρησε στις 17 Σεπτεμβρίου του 1991) έως και το σχετικά πρόσφατο 2002, οι αλλαγές στον πηγαίο κώδικα διακινούνταν υπό τη μορφή patches και archives. Δεν γινόταν χρήση κάποιου VCS, κυρίως λόγω της αποστροφής που έτρεφε ο Linus προς τα συγκεντρωτικά συστήματα του είδους. Το 2002, ωστόσο, η ανάπτυξη του Linux kernel πέρασε υπό την εποπτεία του BitKeeper, ενός κατανεμημένου VCS που ικανοποιούσε τα τεχνικά κριτήρια του Torvalds. Αν και την εποχή το BitKeeper αποτελούσε ιδιόκτητο λογισμικό, στον Linus και σε άλλους μηχανικούς λογισμικού δόθηκε δωρεάν και πλήρης πρόσβαση στο σύστημα.

Τον Απρίλιο του 2005 η BitMover, η εταιρεία πίσω από το BitKeeper, σταμάτησε να υποστηρίζει την ανάπτυξη του Linux kernel και τερμάτισε το ιδιαίτερο καθεστώς δωρεάν χρήσης της υπηρεσίας για τους kernel developers. Αιτία ήταν οι προσπάθειες του Andrew Tridgell, πνευματικού πατέρα της SAMBA και πρωτεργάτη του rsync, ν’ αναπτύξει ανοικτό λογισμικό το οποίο θα συνεργαζόταν με τα αποθετήρια του BitKeeper μέσω τεχνικών reverse engineering.

Ως αποτέλεσμα, ο Linus Torvalds ηγήθηκε της φιλόδοξης προσπάθειας για την ανάπτυξη μιας νέας πλατφόρμας διαχείρισης εκδόσεων. Επρόκειτο για το Git, ένα κατανεμημένο σύστημα που γράφτηκε μέσα σε δύο μόλις εβδομάδες. Πολύ γρήγορα, το Git εξελίχθηκε σε ένα αυτόνομο πρότζεκτ κι από νωρίς γνώρισε ευρεία αποδοχή μεταξύ των developers. Οι σχεδιαστικοί στόχοι του Git υπαγόρευαν την ανάπτυξη ενός απλού, γρήγορου και κατανεμημένου VCS, το οποίο θα ήταν ικανό να διαχειρίζεται χιλιάδες παράλληλα branches, να υποστηρίζει μεγάλα πρότζεκτ όπως εκείνο του Linux kernel, αλλά και να ενσωματώνει μηχανισμούς ασφαλείας από τις καταστροφές ή ακόμη κι από την εσκεμμένη δολιοφθορά. Από τη γέννησή του, το 2005, το Git κατάφερε να υλοποιήσει όλους αυτούς τους στόχους.

Χαρακτηριστικά που το κάνουν να ξεχωρίζει
Παραδοσιακά συστήματα ελέγχου εκδόσεων, όπως το CVS και το Subversion, βλέπουν τις πληροφορίες που διαχειρίζονται ως ακολουθίες αλλαγών σε επίπεδο αρχείου. Μ’ άλλα λόγια, επιτηρούν ένα σύνολο αρχείων και για κάθε μέλος του συνόλου τηρούν μια ακολουθία αλλαγών, η οποία εξελίσσεται συν τω χρόνω. Προφανώς, οι ακολουθίες δεν εξελίσσονται με τον ίδιο ρυθμό, αφού δεν αλλάζουν όλα τα αρχεία με την ίδια συχνότητα. Κανένα VCS πάντως δεν έχει πρόβλημα μ’ αυτό το φαινόμενο.

Το Git ακολουθεί μια εντελώς διαφορετική λογική: Θεωρεί τα δεδομένα που διαχειρίζεται ως μια ροή (stream) διακριτών στιγμιότυπων (snapshots) ενός μικρού συστήματος αρχείων (filesystem). Με το που ξεκινάμε ένα νέο πρότζεκτ στο Git, δημιουργούμε ουσιαστικά ένα νέο σύστημα αρχείων. Στο εξής, κάθε φορά που κάνουμε ένα commit ή αποθηκεύουμε την κατάσταση του πρότζεκτ, το Git είναι σαν να παίρνει μια φωτογραφία του όλου τοπίου και να την αποθηκεύει για μελλοντική αναφορά. Στην πραγματικότητα, αυτό που κάνει είναι περισσότερο αποδοτικό σε σύγκριση με ό,τι υπονοείται από την παρομοίωση με τη φωτογραφία. Πράγματι, αν τη στιγμή δημιουργίας στιγμιότυπου υπάρχουν αρχεία που δεν έχουν αλλάξει, τότε αντί να τα αποθηκεύσει στο νέο στιγμιότυπο δημιουργεί απλά συνδέσμους προς τις πιο πρόσφατες αποθηκευμένες εκδοχές των εν λόγω αρχείων.

Κατά την εργασία μας εξάλλου με το Git, όλες σχεδόν οι ενέργειες είναι τοπικές και σπανίως εμπλέκεται κάποιο απομακρυσμένο μηχάνημα. Αμέσως αμέσως αυτό σημαίνει ότι ξεχνάμε τον παράγοντα του network latency. Υποθέστε, για παράδειγμα, ότι θέλουμε να δούμε τις αλλαγές που έχουν συμβεί σε ένα αρχείο, συγκρίνοντας το σημερινό του περιεχόμενο μ’ εκείνο που είχε τρεις εβδομάδες πριν. Χωρίς να επικοινωνήσει το Git με άλλον υπολογιστή, θα βρει το αρχείο όπως ήταν τρεις εβδομάδες πριν, αμέσως θα προχωρήσει σ’ έναν υπολογισμό διαφορών τοπικά και, τέλος, θα μας τις εμφανίσει. Ακόμη λοιπόν κι αν βρεθούμε offline θα μπορούμε να δουλεύουμε στο πρότζεκτ και να κάνουμε τα commits μας και, αργότερα, όταν θα είμαστε και πάλι online, το πολύ πολύ να στείλουμε τις αλλαγές σε κάποιον απομακρυσμένο server.

Ό,τι πρέπει για να ξεκινήσετε
Αν θέλετε να μάθετε ένα VCS και να το κάνετε αναπόσπαστο μέρος της εργασίας σας, καλό είναι να γνωρίζετε ότι εκτός από την ταχύτητα και την ευελιξία το Git σας επιτρέπει να πειραματίζεστε με ασφάλεια. Οτιδήποτε κι αν κάνετε με το Git, ουσιαστικά προσθέτετε στοιχεία στη βάση δεδομένων του. Είναι εξαιρετικά δύσκολο να κάνετε κάτι μη αναστρέψιμο ή να χάσετε δεδομένα. Σίγουρα υπάρχει το ενδεχόμενο για μπερδέματα ή ακόμη και για απώλεια αρχείων πριν από το commit, μετά από κάθε commit όμως είναι δύσκολο να χάσετε κάτι — ειδικά όταν ανεβάζετε το πρότζεκτ σας σε απομακρυσμένο repository.

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

Σας άρεσε το άρθρο; Αν ναι, τι θα λέγατε για ένα tip στο PayPal;

2 Responses to “VCS και Git: Τι στο καλό είναι και γιατί πρέπει να νοιαστείτε”

  1. Darfonicus | 05/07/2016 at 01:33

    Με συγχωρείτε αλλά θαρρώ πως στην τρίτη σειρά από το τέλος της τρίτης παραγράφου από το τέλος του άρθρου θέλετε μάλλον να γράψετε “…αν βρεθούμε offline…” αντί για “…αν βρεθούμε online…” .

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων