-
1. Ξεκινώντας με το Git
-
2. Τα θεμελιώδη στοιχεία του Git
-
3. Διακλαδώσεις στο Git
-
4. Το Git στον διακομιστή
- 4.1 Τα πρωτόκολλα
- 4.2 Εγκατάσταση του Git σε διακομιστή
- 4.3 Δημιουργία δημόσιου κλειδιού SSH
- 4.4 Στήσιμο του διακομιστή
- 4.5 Δαίμονες του Git
- 4.6 Έξυπνο HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Επιλογές φιλοξενίας από τρίτους
- 4.10 Ανακεφαλαίωση
-
5. Κατανεμημένο Git
-
6. GitHub
-
7. Εργαλεία του Git
- 7.1 Επιλογή αναθεώρησης
- 7.2 Διαδραστική εργασία με το στάδιο καταχώρισης
- 7.3 stash και clean
- 7.4 Υπογραφή της δουλειάς μας
- 7.5 Αναζήτηση
- 7.6 Η ιστορία ξαναγράφεται
- 7.7 Απομυθοποίηση της reset
- 7.8 Συγχωνεύσεις για προχωρημένους
- 7.9 Rerere
- 7.10 Αποσφαλμάτωση με το Git
- 7.11 Λειτουργικές υπομονάδες
- 7.12 Δεμάτιασμα δεδομένων
- 7.13 Replace
- 7.14 Αποθήκευση διαπιστευτηρίων
- 7.15 Ανακεφαλαίωση
-
8. Εξατομίκευση του Git
-
9. Το Git και άλλα συστήματα
- 9.1 Το Git ως πελάτης
- 9.2 Μετανάστευση στο Git
- 9.3 Ανακεφαλαίωση
-
10. Εσωτερική λειτουργία του Git
- 10.1 Διοχετεύσεις και πορσελάνες
- 10.2 Αντικείμενα του Git
- 10.3 Αναφορές του Git
- 10.4 Πακετάρισμα αρχείων
- 10.5 Τα refspec
- 10.6 Πρωτόκολλα μεταφοράς
- 10.7 Διατήρηση και ανάκτηση δεδομένων
- 10.8 Μεταβλητές περιβάλλοντος
- 10.9 Ανακεφαλαίωση
-
A1. Appendix A: Το Git σε άλλα περιβάλλοντα
- A1.1 Γραφικές διεπαφές
- A1.2 Το Git στο Visual Studio
- A1.3 Git στο Eclipse
- A1.4 Το Git στο Bash
- A1.5 Το Git στο Zsh
- A1.6 Το Git στο Powershell
- A1.7 Ανακεφαλαίωση
-
A2. Appendix B: Ενσωμάτωση του Git στις εφαρμογές μας
- A2.1 Γραμμή εντολών Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Εντολές Git
- A3.1 Ρύθμιση και διαμόρφωση
- A3.2 Λήψη και δημιουργία έργων
- A3.3 Βασική λήψη στιγμιοτύπων
- A3.4 Διακλάδωση και συγχώνευση
- A3.5 Κοινή χρήση και ενημέρωση έργων
- A3.6 Επιθεώρηση και σύγκριση
- A3.7 Αποσφαλμάτωση
- A3.8 Επιθέματα
- A3.9 Ηλεκτρονικό ταχυδρομείο
- A3.10 Εξωτερικά Συστήματα
- A3.11 Διοίκηση
- A3.12 Εντολές διοχέτευσης
5.1 Κατανεμημένο Git - Κατανεμημένες ροές εργασίας
Τώρα που έχουμε εγκαταστήσει ένα απομακρυσμένο αποθετήριο Git ως ένα σημείο στο οποίο όλοι οι προγραμματιστές θα μοιράζονται τον κώδικά τους και είμαστε εξοικειωμένοι με τις βασικές εντολές του Git όσον αφορά σε τοπικές ροές εργασίας, θα εξετάσουμε πώς να χρησιμοποιούμε ορισμένες από τις κατανεμημένες ροές εργασίας που μας προσφέρει το Git.
Σε αυτό το κεφάλαιο, θα δούμε πώς θα συνεργαστούμε με το Git σε ένα κατανεμημένο περιβάλλον ως συνεργάτες και ως ενοποιητής. Δηλαδή, θα μάθουμε πώς να συνεισφέρουμε κώδικα σε ένα έργο με επιτυχία και να το κάνουμε κατά το δυνατό ευκολότερο τόσο για εμάς τους ίδιους όσο και για τον διαχειριστή του έργου. Επίσης θα δούμε πώς θα διαχειριζόμαστε με επιτυχία ένα έργο με πολλούς συμβεβλημένους προγραμματιστές.
Κατανεμημένες ροές εργασίας
Σε αντίθεση με τα Κεντρικά Συστήματα Ελέγχου Έκδοσεων (CVCS), η κατανεμημένη φύση του Git μάς επιτρέπει να είμαστε πολύ πιο ευέλικτοι στο πώς θα συνεργάζονται οι προγραμματιστές στα έργα. Στα συγκεντρωτικά συστήματα κάθε προγραμματιστής είναι ένας κόμβος που εργάζεται λίγο πολύ εξίσου σε έναν κεντρικό κόμβο. Ωστόσο, στο Git, κάθε προγραμματιστής είναι δυνητικά τόσο κόμβος όσο και κεντρικό σημείο —δηλαδή, κάθε προγραμματιστής μπορεί να συνεισφέρει κώδικα σε άλλα αποθετήρια και να διαχειρίζεται ένα δημόσιο αποθετήριο στο οποίο άλλοι μπορούν να βασίσουν τη δική τους εργασία και στο οποίο μπορούν να συνεισφέρουν. Αυτό παρέχει ένα ευρύ φάσμα δυνατών ροών εργασίας για το έργο μας ή/και την ομάδα μας· θα καλύψουμε μερικά συνηθισμένα μοντέλα που εκμεταλλεύονται αυτήν την ευελιξία. Θα αναλύσουμε τα δυνατά σημεία και τις πιθανές αδυναμίες κάθε μοντέλου· μπορούμε να επιλέξουμε μόνον ένα που θέλουμε να χρησιμοποιήσουμε ή να απομονώσουμε διαφορετικές λειτουργίες από το καθένα και να τις συνταιριάξουμε.
Συγκεντρωτική ροή εργασίας
Στα συγκεντρωτικά συστήματα υπάρχει γενικά ένα ενιαίο μοντέλο συνεργασίας —η συγκεντρωτική ροή εργασίας. Ένας μόνον κεντρικός κόμβος ή αποθετήριο μπορεί να δεχθεί κώδικα και όλοι συγχρονίζουν το έργασία τους με αυτόν. Ένας αριθμός προγραμματιστών είναι περιφερειακοί κόμβοι —καταναλωτές αυτού του κεντρικού κόμβου— και συγχρονίζονται με αυτό το σημείο.

Αυτό σημαίνει ότι εάν δύο προγραμματιστές κλωνοποιήσουν από τον κεντρικό κόμβο και κάνουν αλλαγές και οι δύο, ο πρώτος προγραμματιστής που θα ωθήσει τις αλλαγές τους μπορεί να το κάνει χωρίς προβλήματα. Ο δεύτερος προγραμματιστής πρέπει να συγχωνευθεί με την εργασία του πρώτου πριν ωθήσει τις αλλαγές, ώστε να μην αντικαταστήσει τις αλλαγές του πρώτου προγραμματιστή. Αυτή η ιδέα είναι εξίσου αληθινή τόσο στο Git όσο και στο Subversion (ή οποιοδήποτε CVCS), και αυτό το μοντέλο λειτουργεί απολύτως καλά στο Git.
Εάν είμαστε ήδη εξοικειωμένοι με μια συγκεντρωτική κεντρική ροή εργασίας στην εταιρεία ή την ομάδα μας, μπορούμε εύκολα να συνεχίσουμε να χρησιμοποιούμε αυτήν τη ροή εργασίας με το Git. Απλά δημιουργούμε ένα μοναδικό αποθετήριο και δίνουμε σε όλα τα μέλη της ομάδας μας δικαίωμα ώθησης (push access)· το Git δεν επιτρέπει στους χρήστες να επανεγγράψουν ο ένας τη δουλειά του άλλου. Ας υποθέσουμε ότι ο John και η Jessica αρχίζουν να εργάζονται την ίδια στιγμή. Ο John ολοκληρώνει τις αλλαγές του και τις ωθεί στον διακομιστή. Στη συνέχεια η Jessica προσπαθεί να ωθήσει τις αλλαγές τη, αλλά ο διακομιστής τις απορρίπτει. Της λέει ότι προσπαθεί να ωθήσει αλλαγές χωρίς ταχυπροώθηση και ότι δεν θα μπορέσει να το κάνει μέχρι να ανακτήσει τις αλλαγές που υπάρχουν ήδη και να τις συγχωνεύσει. Αυτή η ροή εργασίας είναι ελκυστική για πολλούς, επειδή είναι ένα μοντέλο με το οποίο είναι εξοικειωμένοι και έχουν άνεση.
Αυτό δεν περιορίζεται μόνο στις μικρές ομάδες. Με το μοντέλο διακλάδωσης του Git είναι δυνατό για εκατοντάδες προγραμματιστές να δουλέψουν με επιτυχία σε ένα μόνο έργο μέσω δεκάδων κλάδων ταυτόχρονα.
Ροή εργασίας με διαχειριστή ενσωμάτωσης
Επειδή το Git μάς επιτρέπει να έχουμε πολλαπλά απομακρυσμένα αποθετήρια, είναι δυνατό να έχουμε μια ροή εργασίας στην οποία κάθε προγραμματιστής έχει δικαίωμα εγγραφής στο δικό του δημόσιο αποθετήριο και δικαίωμα ανάγνωσης σε όλους τους άλλους. Αυτό το σενάριο περιλαμβάνει συχνά ένα κανονικό αποθετήριο που αντιπροσωπεύει το “επίσημο” έργο. Για να συνεισφέρουμε σε αυτό το έργο, δημιουργούμε τον δικό μας δημόσιο κλώνο του έργου και ωθούμε τις αλλαγές μας σε αυτόν. Στη συνέχεια, μπορούμε να στείλουμε ένα αίτημα στον διαχειριστή του κύριου έργου να έλξει τις αλλαγές μας. Τότε ο διαχειριστής μπορεί να προσθέσει το αποθετήριό μας ως απομακρυσμένο, να δοκιμάσει τις αλλαγές μας τοπικά, να τις συγχωνεύσει στον κλάδο του και να τις ωθήσει στο αποθετήριό του. Η διαδικασία λειτουργεί ως εξής (βλ. Ροή εργασίας με διαχειριστη ενσωμάτωσης.):
-
Ο διαχειριστής του έργου ωθεί στο δημόσιο αποθετήριό του.
-
Ένας συνεισφέρων κλωνοποιεί αυτό το αποθετήριο και κάνει αλλαγές.
-
Ο συνεισφέρων ωθεί στο δικό του δημόσιο αντίγραφο.
-
Ο συνεισφέρων αποστέλλει στον διαχειριστή ένα μήνυμα ηλεκτρονικού ταχυδρομείου ζητώντας του να κάνει αλλαγές.
-
Ο διαχειριστής προσθέτει το αποθετήριο του συνεισφέροντος ως απομακρυσμένο και συγχωνεύει τοπικά.
-
Ο διαχειριστής ωθεί τις συγχωνευμένες αλλαγές στο κύριο αποθετήριο.

Αυτή είναι μια πολύ συνηθισμένη ροή εργασίας με εργαλεία όπως το GitHub ή το GitLab, που βασίζονται σε κεντρικούς κόμβους και στην οποία είναι εύκολο να κλωνοποιήσουμε ένα έργο και να ωθήσουμε τις αλλαγές μας στον δικό μας κλώνο, όπου μπορούν να τις δουν όλοι. Ένα από τα κύρια πλεονεκτήματα αυτής της προσέγγισης είναι ότι μπορούμε να συνεχίσουμε να εργαζόμαστε και ο διαχειριστής του κύριου αποθετηρίου μπορεί να έλξει τις αλλαγές μας όποτε θέλει. Οι συνεισφέροντες δεν χρειάζεται να περιμένουν το έργο να ενσωματώσει τις αλλαγές τους —ο καθένας μπορεί να εργαστεί με τον δικό του ρυθμό.
Ροή εργασίας δικτάτορα και υπολοχαγών
Αυτή είναι μια παραλλαγή της ροής εργασίας πολλαπλών αποθετηρίων. Χρησιμοποιείται γενικά από τεράστια έργα με εκατοντάδες συνεργάτες· ένα διάσημο παράδειγμα είναι ο πυρήνας του Linux. Διάφοροι διαχειριστές ενοποίησης είναι υπεύθυνοι για ορισμένα τμήματα του αποθετηρίου· αυτοί ονομάζονται υπολοχαγοί. Όλοι οι υπολοχαγοί έχουν έναν διευθυντή ενσωμάτωσης γνωστό και ως καλόβουλο δικτάτορα. Το αποθετήριο του καλόβουλου δικτάτορα χρησιμεύει ως αποθετήριο αναφοράς από το οποίο όλοι οι συνεργάτες πρέπει να έλξουν (αρχεία). Η διαδικασία λειτουργεί έτσι (βλ. Ροή εργασίας με καλόβουλο δικτάτορα.):
-
Οι απλοί προγραμματιστές ασχολούνται με τον θεματικό κλάδο τους και αλλάζουν τη βάση της εργασίας τους στον κλάδο
master
. Ο κλάδοςmaster
είναι αυτός του δικτάτορα. -
Οι υπολοχαγοί συγχωνεύουν τους κλάδους των προγραμματιστών ο καθένας στον δικό του στον κλάδο
master
. -
Ο δικτάτορας συγχωνεύει τους κλάδους
master
των υπολοχαγών στον κλάδο `master`του δικτάτορα. -
Ο δικτάτορας σπρώχνει τον δικό του κλάδο
master
στο αποθετήριο αναφοράς, έτσι ώστε οι άλλοι προγραμματιστές να μπορέσουν να αλλάξουν τη βάση τους σε αυτόν.

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