1.1 Ξεκινώντας με το Git - Σχετικά με τον έλεγχο εκδόσεων

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

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

Ένα από τα πιο δημοφιλή VCS ήταν το σύστημα RCS το οποίο διανέμεται ακόμα σε πολλούς υπολογιστές. Το RCS δουλεύει χρησιμοποιώντας συλλογές από επιθέματα (patches) (που είναι οι διαφορές μεταξύ αρχείων) σε μια συγκεκριμένη μορφή στον δίσκο. Έπειτα, μπορεί να ξαναδημιουργήσει κάθε αρχείο όπως ήταν σε οποιοδήποτε χρονικό σημείο εφαρμόζοντας όλα τα επιθέματα.

Το επόμενο σημαντικό πρόβλημα που αντιμετώπισαν οι προγραμματιστές ήταν η ανάγκη για συνεργασία με προγραμματιστές άλλων συστημάτων. Για την αντιμετώπιση του συγκεκριμένου προβλήματος, αναπτύχθηκαν τα συγκεντρωτικά συστήματα ελέγχου εκδόσεων (Centralized Version Control Systems, CVCSs). Τα συστήματα αυτά (όπως το CVS, το Subversion και το Perforce) έχουν έναν διακομιστή (server), ο οποίος περιέχει όλα τα αρχεία και κάποιους πελάτες (clients) οι οποίοι ενημερώνουν (check out) τα αρχεία τους από αυτή την κεντρική τοποθεσία. Για πολλά χρόνια, αυτό ήταν και το καθιερωμένο πρότυπο για τα συστήματα ελέγχου εκδόσεων.

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

Η συγκεκριμένη μέθοδος έχει όμως και σημαντικά μειονεκτήματα. Το πιο προφανές είναι το γεγονός ότι μια βλάβη στον κεντρικό διακομιστή προκαλεί την αποτυχία όλου του συστήματος. Αν ο διακομιστής πέσει για μία ώρα, τότε κατά τη διάρκεια αυτής της ώρας κανείς δεν μπορεί να συνεργαστεί με το VCS ή να αποθηκεύσει αλλαγές σε αυτό. Αν για παράδειγμα ο σκληρός δίσκος στον οποίο βρίσκεται η κεντρική βάση δεδομένων καταστραφεί και δεν έχουν κρατηθεί τα απαραίτητα αντίγραφα ασφαλείας τότε χάνονται τα πάντα — ολόκληρο το ιστορικό του έργου χάνεται εκτός από στιγμιότυπα (snapshots) του έργου που μπορεί να έχουν κρατήσει στους υπολογιστές τους κάποιοι προγραμματιστές. Τα τοπικά VCS πάσχουν από το ίδιο πρόβλημα — όταν το ιστορικό ενός έργου βρίσκεται σε ένα και μοναδικό μέρος τότε υπάρχει ο κίνδυνος να χαθούν τα πάντα.

Στο σημείο αυτό έρχονται τα κατανεμημένα (Distributed) DVCS. Σε ένα κατανεμημένο σύστημα (όπως το Git, το Mercurial ή το Darcs) οι πελάτες δεν ανακτούν μόνο το τελευταίο στιγμιότυπο των αρχείων τους, αλλά ολόκληρο το αποθετήριο (repository), συμπεριλαμβανομένης και ολόκληρου του ιστορικού. Συνεπώς, στην περίπτωση που ο διακομιστής πεθάνει, τα τοπικά αποθετήρια που έχουν οι πελάτες μπορούν να χρησιμοποιηθούν ώστε να επαναφέρουν τα δεδομένα του. Κάθε κλώνος είναι ένα πλήρες αντίγραφο ασφαλείας όλων των δεδομένων.

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