Git
Chapters ▾ 2nd Edition

4.1 Το Git στον διακομιστή - Τα πρωτόκολλα

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

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

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

Ένα απομακρυσμένο αποθετήριο είναι γενικά ένα γυμνό αποθετήριο --ένα αποθετήριο Git που δεν έχει κατάλογο εργασίας. Επειδή το αποθετήριο χρησιμοποιείται μόνο ως σημείο συνεργασίας, δεν έχει κανένα νόημα να έχει κάποιο στιγμιότυπο στον δίσκο· αποτελείται μόνο από τα δεδομένα του Git. Με απλούστερα λόγια, το περιεχόμενο του καταλόγου .git του έργου μας είναι ένα γυμνό αποθετήριο και τίποτα άλλο.

Τα πρωτόκολλα

Το Git μπορεί να χρησιμοποιήσει τέσσερα συνηθισμένα πρωτόκολλα για τη μεταφορά δεδομένων: Local, HTTP, Secure Shell (SSH) και Git. Θα συζητήσουμε τι είναι αυτά και σε ποιες βασικές περιστάσεις θα θέλαμε (ή δεν θα θέλαμε) να τα χρησιμοποιήσουμε.

Το τοπικό πρωτόκολλο

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

Εάν διαθέτουμε ένα κοινόχρηστο σύστημα αρχείων, μπορούμε να κλωνοποιήσουμε, να ωθήσουμε και να έλξουμε από ένα αποθετήριο που βασίζεται σε τοπικά αρχεία. Για να κλωνοποιήσουμε ένα αποθετήριο όπως αυτό ή για να το προσθέσουμε ως απομακρυσμένο σε ένα υπάρχον έργο, χρησιμοποιούμε τη διαδρομή (path) του αποθετήριο ως διεύθυνση URL. Για παράδειγμα, για να κλωνοποιήσουμε ένα τοπικό αποθετήριο, μπορούμε να εκτελέσουμε κάτι σαν:

$ git clone /opt/git/project.git

Ή μπορούμε να κάνουμε αυτό:

$ git clone file:///opt/git/project.git

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

Για να προσθέσουμε ένα τοπικό αποθετήριο σε ένα υπάρχον έργο Git, μπορούμε να εκτελέσουμε κάτι σαν:

$ git remote add local_proj /opt/git/project.git

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

Τα υπέρ

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

Αυτή είναι επίσης μια καλή επιλογή για γρήγορη λήψη της εργασίας από το αποθετήριο εργασίας κάποιου άλλου. Εάν εμείς και ένας συνεργάτης εργάζόμαστε στο ίδιο έργο και θέλουμε να ελέγξουμε κάτι, η εκτέλεση μιας εντολής όπως git pull /home/john/project είναι συχνά ευκολότερη από ό,τι ο συνεργάτης να ωθήσει σε έναν απομακρυσμένο διακομιστή και εμείς να ανακτήσουμε από αυτόν.

Τα κατά

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

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

Τέλος, το πρωτόκολλο αυτό δεν προστατεύει το αποθετήριο από τυχαίες αστοχίες. Κάθε χρήστης έχει πλήρη πρόσβαση στο κέλυφος στο “απομακρυσμένο” αποθετήριο και τίποτα δεν τους εμποδίζει να αλλάξουν ή να αφαιρέσουν εσωτερικά αρχεία του Git και να καταστρέψουν το αποθετήριο.

Πρωτόκολλα HTTP

Το Git μπορεί να επικοινωνήσει μέσω HTTP σε δύο διαφορετικές λειτουργίες. Πριν από το Git 1.6.6 υπήρχε μόνον ένας τρόπος που θα μπορούσε να γίνει αυτό, και αυτός ήταν πολύ απλοϊκός και γενικά μόνο για ανάγνωση. Στην έκδοση 1.6.6 εισήχθη ένα νέο, πιο έξυπνο πρωτόκολλο το οποίο περιλάμβανε τη δυνατότητα του Git να διαπραγματεύεται έξυπνα τη μεταφορά δεδομένων με τρόπο παρόμοιο με τον τρόπο με τον οποίο το κάνει με το SSH. Τα τελευταία χρόνια αυτό το νέο πρωτόκολλο HTTP έχει γίνει πολύ δημοφιλές, καθώς είναι απλούστερο για τον χρήστη και πιο έξυπνο σχετικά με τον τρόπο επικοινωνίας. Η νεότερη έκδοση αναφέρεται συχνά ως το πρωτόκολλο “έξυπνο” HTTP και ο παλαιότερος τρόπος ως “χαζό” HTTP. Θα καλύψουμε πρώτα το πιο πρόσφατο “έξυπνο” HTTP.

Έξυπνο HTTP

Το πρωτόκολλο “έξυπνο” HTTP έχει παρόμοια λειτουργία με τα πρωτόκολλα SSH ή Git, αλλά τρέχει πάνω από τις τυπικές θύρες για HTTP/S και μπορεί να χρησιμοποιήσει διάφορους μηχανισμούς HTTP ελέγχου ταυτότητας, που σημαίνει ότι είναι συχνά πιο εύκολο για τον χρήστη από ό,τι είναι για παράδειγμα το SSH, αφού είναι δυνατό να χρησιμοποιηθεί βασικός έλεγχος ταυτότητας με όνομα χρήστη/κωδικό πρόσβασης, αντί να χρειάζεται να ρυθμίσουμε τα κλειδιά SSH.

Αυτός φαίνεται ότι είναι πλέον ο πιο δημοφιλής τρόπος χρήσης του Git, αφού μπορεί να ρυθμιστεί τόσο για να ανώνυμη ανάκτηση όπως κάνει το πρωτόκολλο git:// όσο και για ώθηση με ταυτοποίηση και κρυπτογράφηση όπως το πρωτόκολλο SSH. Αντί να χρειάζεται να ορίσουμε διαφορετικές διευθύνσεις URL για αυτά τα δύο πράγματα, μπορούμε πλέον να χρησιμοποιήσουμε μια ενιαία διεύθυνση URL και για τα δύο. Αν προσπαθήσουμε να ωθήσουμε και το αποθετήριο απαιτεί ταυτοποίηση (όπως θα έπρεπε), ο διακομιστής μπορεί να ζητήσει όνομα χρήστη και κωδικό πρόσβασης. Το ίδιο ισχύει και για την πρόσβαση ανάγνωσης.

Στην πραγματικότητα, για υπηρεσίες όπως το GitHub, η διεύθυνση URL που χρησιμοποιούμε για την προβολή του αποθετηρίου online (για παράδειγμα, https://github.com/schacon/simplegit[]) είναι η ίδια διεύθυνση URL που μπορούμε να χρησιμοποιήσουμε για να κλωνοποιήσουμε και, εφόσον έχουμε πρόσβαση, να ωθήσουμε.

Χαζό HTTP

Εάν ο διακομιστής δεν ανταποκρίνεται σε μια υπηρεσία έξυπνου HTTP του Git, ο πελάτης θα προσπαθήσει να χρησιμοποιήσει στο απλούστερο πρωτόκολλο “χαζό” HTTP. Το χαζό πρωτόκολλο αναμένει ότι το γυμνό αποθετήριο Git να εξυπηρετείται σαν να επρόκειτο για κανονικά αρχεία από τον διακομιστή ιστού. Η ομορφιά του πρωτοκόλλου χαζού HTTP είναι η απλότητα στη δημιουργία του. Βασικά, το μόνο που έχουμε να κάνουμε είναι να τοποθετήσουμε ένα γυμνό αποθετήριο Git κάτω από τον ριζικό κατάλογο του εγγράφου HTTP και να δημιουργήσουμε ένα συγκεκριμένο άγκιστρο post-update, και αυτό ήταν όλο (βλ. Τα άγκιστρα του Git). Σε αυτό το σημείο, οποιοσδήποτε έχει πρόσβαση στον διακομιστή ιστού κάτω από τον οποίο έχουμε κρεμάσει το αποθετήριο, μπορεί επίσης να κλωνοποιήσει το αποθετήριο. Για να επιτρέψουμε την πρόσβαση ανάγνωσης στο αποθετήριό μας μέσω HTTP, κάνουμε κάτι σαν αυτό:

$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update

Αυτό είναι όλο. Το άγκιστρο post-update (που έρχεται με το Git) τρέχει την κατάλληλη εντολή (git update-server-info) για να κάνει την ανάκτηση και κλωνοποίηση μέσω HTTP να λειτουργήσουν σωστά. Αυτή η εντολή εκτελείται όταν ωθούμε σε αυτό το αποθετήριο (ίσως μέσω SSH)· τότε, άλλοι μπορούν να κλωνοποιήσουν με κάτι σαν:

$ git clone https://example.com/gitproject.git

Στη συγκεκριμένη περίπτωση, χρησιμοποιούμε τη διαδρομή /var/www/htdocs που είναι κοινή για διακομιστές Apache, αλλά μπορούμε να χρησιμοποιήσουμε οποιονδήποτε στατικό διακομιστή ιστού —απλά τοποθετούμε το γυμνό αποθετήριο στη διαδρομή του. Τα δεδομένα Git διακομίζονται ως απλά στατικά αρχεία (βλ. ενότητα Εσωτερική λειτουργία του Git για λεπτομέρειες σχετικά με τον τρόπο με τον οποίο εξυπηρετείται).

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

Τα υπέρ

Θα επικεντρωθούμε στα πλεονεκτήματα της έξυπνης έκδοσης του πρωτοκόλλου HTTP.

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

Μπορούμε επίσης να διαθέτουμε τα αποθετήριά μας μόνο για ανάγνωση μέσω HTTPS, πράγμα που σημαίνει ότι μπορούμε να κρυπτογραφήσουμε τη μεταφορά του περιεχομένου· ή μπορούμε να φτάσουμε μέχρι το σημείο να κάνουμε τους πελάτες να χρησιμοποιούν ειδικά υπογεγραμμένα πιστοποιητικά SSL.

Ένα άλλο υπέρ είναι ότι το HTTP/S είναι τόσο διαδεδομένο πρωτόκολλο που συχνά τα εταιρικά τείχη προστασίας (firewall) ρυθμίζονται με τέτοιον τρόπο ώστε να επιτρέπουν την κίνηση δεδομένων μέσω αυτών των θυρών.

Τα κατά

Το Git πάνω από HTTP/S μπορεί να είναι λίγο πιο δύσκολο να ρυθμιστεί σε σύγκριση με το SSH σε ορισμένους διακομιστές. Εκτός από αυτό, τα άλλα πρωτόκολλα δεν έχουν κανένα σημαντικό πλεονέκτημα σε σύγκριση με το πρωτόκολλο “έξυπνο” HTTP για τη διάθεση του Git.

Αν χρησιμοποιούμε HTTP για την ταυτοποίηση ώθησης, η παροχή των διαπιστευτηρίων είναι κάποιες φορές πιο πολύπλοκη από τη χρήση κλειδιών μέσω SSH. Ωστόσο, υπάρχουν αρκετά εργαλεία προσωρινής αποθήκευσης διαπιστευτηρίων που μπορούμε να χρησιμοποιήσουμε, συμπεριλαμβανομένης της πρόσβασης μέσω Keychain στο OS X και του Credential Manager στα Windows, που καθιστούν τη διαδικασία ταυτοποίησης αρκετά ανώδυνη. Στην ενότητα Αποθήκευση διαπιστευτηρίων μπορούμε να δούμε πώς μπορούμε να ρυθμίσουμε ασφαλή προσωρινή αποθήκευση κωδικού πρόσβασης HTTP στο σύστημά μας.

Το πρωτόκολλο SSH

Ένα κοινό πρωτόκολλο μεταφοράς για το Git όταν η αυτο-φιλοξενείται είναι το SSH. Αυτό οφείλεται στο ότι η πρόσβαση σε διακομιστές μέσω SSH είναι ήδη ρυθμισμένη —και αν δεν είναι, είναι εύκολο να γίνει. Το SSH είναι επίσης πρωτόκολλο ταυτοποιημένου δικτύου· και επειδή είναι πανταχού παρόν είναι γενικά εύκολο να εγκαταστασθεί και να χρησιμοποιηθεί.

Για να κλωνοποιήσουμε ένα αποθετήριο Git πάνω από SSH, μπορούμε να ορίσουμε το URL ssh:// ως εξής:

$ git clone ssh://user@server/project.git

Ή μπορούμε να χρησιμοποιήσουμε τη συντομότερη σύνταξη τύπου scp για το πρωτόκολλο SSH:

$ git clone user@server:project.git

Επίσης, είναι δυνατό να μην ορίσουμε κάποιον χρήστη, οπότε το Git θεωρεί ότι είμαστε ο ίδιος χρήστης με τον χρήστη του συστήματός μας.

Τα υπέρ

Τo SSH έχει πολλά πλεονεκτήματα Καταρχάς το SSH είναι σχετικά εύκολο να εγκατασταθεί —οι δαίμονες SSH είναι πολύ συνηθισμένοι, πολλοί διαχειριστές δικτύου έχουν εμπειρία με αυτούς και πολλά λειτουργικά συστήματα είναι εγκατεστημένα με αυτούς ή έχουν εργαλεία να τους διαχειρίζονται. Ακόμα, η πρόσβαση μέσω SSH είναι ασφαλής —όλη η μεταφορά δεδομένων είναι κρυπτογραφημένη και απαιτεί ταυτοποίηση. Τέλος, όπως και το HTTP/S, το Git και το πρωτόκολο Local, SSH είναι αποτελεσματικό με την έννοια ότι συμπιέζει τα δεδομένα όσο είναι δυνατό πριν τη μεταφορά.

Τα κατά

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

Το πρωτόκολλο Git

Το πρωτόκολλο Git είναι ένας ειδικός δαίμονας που έρχεται μαζί με το Git· ακούει σε μία αφοσιωμένη θύρα (9418) που παρέχει μία υπηρεσία παρόμοια με το πρωτόκολλο SSH αλλά με απολύτως καμία ταυτοποίηση. Για να διαθέσουμε ένα αποθετήριο πάνω από το πρωτόκολλο Git, πρέπει να δημιουργήσουμε το αρχείο git-daemon-export-ok —ο δαίμονας δεν θα διαθέτει το αποθετήριο αν δεν έχει αυτό το αρχείο— αλλά πέρα από αυτό δεν υπάρχει καμία ασφάλεια. Είτε το αποθετήριο Git είναι διαθέσιμο σε όλους να το κλωνοποιήσουν είτε σε κανέναν. Αυτό σημαίνει ότι γενικά δεν γίνεται ώθηση πάνω από αυτό το πρωτόκολλο. Μπορούμε να ενεργοποιήσουμε την πρόσβαση ώθησης· αλλά δεδομένης της έλλειψης ταυτοποίησης αν ενεργοποιήσουμε την πρόσβαση ώθησης, οποιοσδήποτε βρίσκει το URL του έργου μας στο Internet, θα μπορεί να ωθήσει στο έργο μας. Είναι προφανές ότι αυτή η συμπεριφορά είναι σπάνια επιθυμητή.

Τα υπέρ

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

Τα κατά

Το μειονέκτημα του πρωτοκόλλου Git είναι η έλλειψη ταυτοποίησης. Γενικά δεν είναι επιθυμητό το πρωτόκολλο Git να είναι το μόνο πρωτόκολλο πρόσβασης στο έργο μας. Γενικά, πρέπει να το συνδυάζουμε με πρόσβαση SSH ή HTTPS για τους λίγους προγραμματιστές που έχουν πρόσβαση ώθησης (εγγραφής) και οι υπόλοιποι προγραμματιστές θα χρησιμοποιούν το git://' για πρόσβαση μόνο για ανάγνωση. Επίσης είναι πιθανότατα το πιο δύσκολο πρωτόκολλο από πλευράς ρύθμισης. Πρέπει να τρέχει το δικό του δαίμονα, που απαιτεί ρύθμιση `xinetd ή κάτι παρόμοιο, το οποίο δεν είναι πάντα απλό να γίνει. Απαιτεί επίσης πρόσβαση στη θύρα 9418 του τείχους προστασίας, θύρα που δεν είναι από τις τυποποιημένες θύρες που επιτρέπουν τα τείχη προστασίας εταιρικών δικτύων. Πίσω από τα τείχη προστασίας μεγάλων εταιριών, αυτή η ασυνήθιστη θύρα είναι συνήθως μπλοκαρισμένη.