9.1 Το Git και άλλα συστήματα - Το Git ως πελάτης

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

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

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

Για να επιδείξουμε αυτήν τη λειτουργικότητα, χρειαζόμαστε ένα τυπικό αποθετήριο SVN στο οποίο έχουμε πρόσβαση εγγραφής. Για να αντιγράψουμε αυτά τα παραδείγματα, θα πρέπει να δημιουργήσουμε ένα αντίγραφο της δοκιμαστικής αποθήκης. Για να γίνει αυτό εύκολα, μπορούμε να χρησιμοποιήσουμε ένα εργαλείο που ονομάζεται svnsync που συνοδεύει το Subversion. Για αυτές τις δοκιμές δημιουργήσαμε ένα νέο αποθετήριο Subversion στο Google Code το οποίο ήταν ένα μερικό αντίγραφο του έργου protobuf, το οποίο είναι ένα εργαλείο που κωδικοποιεί δομημένα δεδομένα για μετάδοση στο δίκτυο.

Πρέπει πρώτα να δημιουργήσουμε ένα νέο τοπικό αποθετήριο Subversion:

Στη συνέχεια, επιτρέπουμε σε όλους τους χρήστες να αλλάξουν revprops —ο εύκολος τρόπος είναι να προσθέσουμε ένα σενάριο pre-revprop-change που πάντα τερματίζει με 0:

Τώρα μπορούμε να συγχρονίσουμε αυτό το έργο με το τοπικό μας μηχάνημα καλώντας την svnsync init με τα αποθετήρια από και προς.

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

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

Τώρα που έχουμε ένα αποθετήριο Subversion στο οποίο έχουμε πρόσβαση εγγραφής, μπορούμε να περάσουμε από μια τυπική ροή εργασίας. Θα ξεκινήσουμε με την εντολή git svn clone, η οποία εισάγει ένα ολόκληρο αποθετήριο Subversion σε ένα τοπικό αποθετήριο Git. Ας θυμηθούμε ότι αν εισάγουμε από ένα πραγματικό αποθετήριο Subversion, θα πρέπει να αντικαταστήσουμε εδώ την file:///tmp/test-svn που υπάρχει εδώ με τη διεύθυνση URL του αποθετηρίου Subversion:

Η παραπάνω εκτελεί το ισοδύναμο δύο εντολών —git svn init ακολουθούμενη από την git svn fetch— στη διεύθυνση URL που παρέχουμε. Αυτό ίσως διαρκέσει λίγο. Το δοκιμαστικό έργο έχει μόνο περίπου 75 υποβολές και η βάση του κώδικα δεν είναι τόσο μεγάλη, αλλά το Git πρέπει να ελέγχει κάθε έκδοση μία μία και να την υποβάλει ξεχωριστά. Για ένα έργο με εκατοντάδες ή χιλιάδες υποβολές, αυτό μπορεί να πάρει κυριολεκτικά ώρες ή ακόμα και ημέρες για να ολοκληρωθεί.

Το τμήμα The -T trunk -b branches -t tags λέει στο Git ότι αυτό το αποθετήριο Subversion ακολουθεί τις βασικές συμβάσεις διακλάδωσης και σήμανσης με ετικέτες. Εάν ονομάσουμε τον κορμό, τους κλάδους ή τις ετικέτες διαφορετικά, μπορούμε να αλλάξουμε αυτές τις επιλογές. Επειδή αυτό είναι τόσο συνηθισμένο, μπορούμε να αντικαταστήσουμε ολόκληρο αυτό το τμήμα με -s, που σημαίνει τυποποιημένη (standard) διάταξη και υπονοεί όλες αυτές τις επιλογές. Η ακόλουθη εντολή είναι ισοδύναμη:

Σε αυτό το σημείο, θα πρέπει να έχουμε ένα έγκυρο αποθετήριο Git που έχει εισάγει τους κλάδους και τις ετικέτες μας:

Ας σημειωθεί πώς το εργαλείο διαχειρίζεται τις ετικέτες Subversion ως απομακρυσμένες ref. Ας ρίξουμε μια πιο προσεκτική ματιά στην εντολή διοχέτευσης show-ref του Git :

Το Git δεν το κάνει αυτό όταν κλωνοποιεί από έναν διακομιστή Git· παρακάτω φαίνεται με τι μοιάζει ένα αποθετήριο με ετικέτες αμριβώς μετά την κλωνοποίηση:

Το Git ανακτά τις ετικέτες κατευθείαν στο φάκελο refs/tags, αντί να τις αντιμετωπίζει ως απομακρυσμένους κλάδους.

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

Στη συνέχεια, πρέπει να ωθήσουμε την αλλαγή μας προς τα πάνω. Αυτό αλλάζει τον τρόπο με τον οποίο εργαζόμαστε με το Subversion —μπορούμε να εκτελέσουμε αρκετές υποβολές τοπικά και στη συνέχεια να τις ωθήσουμε ταυτόχρονα στον διακομιστή Subversion. Για να ωθήσουμε σε έναν διακομιστή Subversion, εκτελούμε την εντολή git svn dcommit:

Αυτό λαμβάνει όλες τις υποβολές που κάναμε πάνω από τον κώδικα του διακομιστή Subversion, πραγματοποιεί μια υποβολή Subversion για καθεμία και μετά ξαναγράφει την τοπική μας υποβολή Git για να συμπεριλάβουμε ένα μοναδικό αναγνωριστικό. Αυτό είναι σημαντικό επειδή σημαίνει ότι όλα τα αθροίσματα ελέγχου SHA-1 για τις υποβολές μας αλλάζουν. Εν μέρει για αυτόν τον λόγο, η εργασία με απομακρυσμένες εκδόσεις του έργου μας σε Git ταυτόχρονα με εργασία σε έναν διακομιστή Subversion δεν είναι καλή ιδέα. Αν κοιτάξουμε την τελευταία υποβολή, μπορούμε να δούμε το νέο git-svn-id που προστέθηκε:

Παρατηρούμε ότι το άθροισμα ελέγχου SHA-1 που ξεκίνησε αρχικά με το 4af61fd όταν υποβάλαμε τώρα αρχίζει με` 95e0222`. Αν θέλουμε να ωθήσουμε τόσο σε έναν διακομιστή Git όσο και σε έναν διακομιστή Subversion, πρέπει πρώτα να ωθήσουμε (dcommit) στον διακομιστή Subversion, επειδή η ενέργεια αυτή αλλάζει τα δεδομένα της υποβολής μας.

Εάν συνεργαζόμαστε με άλλους προγραμματιστές, τότε σε κάποιο σημείο ένας από εμάς θα ωθήσει και μετά κάποιος άλλος θα προσπαθήσει να ωθήσει μια αλλαγή που έρχεται σε σύγκρουση με την πρώτη. Η αλλαγή αυτή θα απορριφθεί μέχρι να συγχωνεύσουμε την εργασία του. Στην git svn, μοιάζει με αυτό:

Για να επιλύσουμε αυτήν την κατάσταση, μπορούμε να εκτελέσουμε την git svn rebase, η οποία καταργεί οποιεσδήποτε αλλαγές στον διακομιστή δεν έχουμε ακόμα και επαντοποθετεί οποιαδήποτε εργασία έχουμε πάνω από αυτό που βρίσκεται στον server:

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

Ας σημειωθεί ότι αντίθετα με το Git, το οποίο απαιτεί να συγχωνεύσουμε την εργασία που έχει γίνει upstream και δεν έχουμε ακόμα τοπικά προτού μπορέσουμε να ωθήσουμε, το git svn μας επιβάλει να το κάνουμε αυτό μόνο αν οι αλλαγές συγκρούονται (όπως ακριβώς λειτουργεί το Subversion). Αν κάποιος άλλος ωθήσει μια αλλαγή σε ένα αρχείο και στη συνέχεια ωθήσουμε μια αλλαγή σε άλλο αρχείο, το dcommit μας θα λειτουργήσει μια χαρά:

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

Θα πρέπει επίσης να εκτελέσουμε αυτήν την εντολή για να έλξουμε αλλαγές από τον διακομιστή Subversion, ακόμη και αν δεν είμαστε έτοιμοι να υποβάλουμε. Μπορούμε να εκτελέσουμε το git svn fetch για να τραβήξουμε τα νέα δεδομένα, αλλά η git svn rebase κάνει την ανάκτηση και στη συνέχεια ενημερώνει τις τοπικές υποβολές μας.

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

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

Ας υποθέσουμε ότι το ιστορικό μας μοιάζει με το ακόλουθο: δημιουργήσαμε έναν κλάδο experiment, κάναμε δύο υποβολές και στη συνέχεια τους συγχωνεύσαμε ξανά στον master. Όταν κάνουμε dcommit, βλέπουμε την εξής έξοδο:

Η εκτέλεση της dcommit σε έναν κλάδο με συγχωνευμένο ιστορικό λειτουργεί καλά, εκτός από το ότι όταν εξετάζουμε το ιστορικό του έργου Git, δεν έχει ξαναγράψει καμία από τις υποβολές που κάναμε στον κλάδο experiment —αντίθετα όλες αυτές οι αλλαγές εμφανίζονται στην έκδοση SVN της μοναδικής υποβολής συγχώνευσης.

Όταν κάποιος άλλος κλωνοποιεί αυτό το έργο, το μόνο που βλέπει είναι ότι η συγχώνευση υποβάλλεται με όλη τη δουλειά που στριμώχνεται σε αυτό, σαν να είχαμε τρέξει git merge --squash· δεν βλέπουν τα δεδομένα υποβολής σχετικά με το από πού προήλθε ή πότε υποβλήθηκε.

Η διακλαδώσεις στο Subversion δεν είναι ίδιες με τις διακλαδώσεις στο Git· αν μπορούμε να αποφύγουμε να τις χρησιμοποιούμε πολύ, αυτό είναι μάλλον το καλύτερο. Ωστόσο, μπορούμε να δημιουργήσουμε κλάδους και τους υποβάλουμε στο Subversion χρησιμοποιώντας την git svn.

Για να δημιουργήσουμε έναν νέο κλάδο στο Subversion, εκτελούμε την git svn branch [όνομα_κλάδου]:

Αυτό ισοδυναμεί με την εντολή svn copy trunk branches/opera στο Subversion και λειτουργεί στον διακομιστή Subversion. Είναι σημαντικό να σημειωθεί ότι αυτή η εντολή δεν μας μεταφέρει σε αυτόν τον κλάδο· εάν υποβάλουμε σε αυτό το σημείο, αυτή η υποβολή θα μεταβεί στον trunk του διακομιστή, όχι στον όπερα.

Το Git υπολογίζει σε ποιον κλάδο πηγαίνουν τα dcommit μας αναζητώντας την άκρη όλων των κλάδων Subversion στο ιστορικό μας —θα πρέπει να έχουμε μόνο ένα και θα πρέπει να είναι το τελευταίο με ένα git-svn-id στο τρέχον ιστορικό του κλάδου μας.

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

Τώρα, εάν θέλουμε να συγχωνεύσουμε τον κλάδο μας opera σε trunk (τον κύριο κλάδο μας), μπορούμε να το κάνουμε με μια κανονική git merge. Αλλά πρέπει να δώσουμε ένα περιγραφικό μήνυμα υποβολής (με -m), αλλιώς η συγχώνευση θα λέει “Merge branch opera” αντί για κάτι χρήσιμο.

Ας θυμηθούμε ότι παρόλο που χρησιμοποιούμε την git merge για να κάνουμε αυτήν τη λειτουργία και η συγχώνευση πιθανόν θα είναι πολύ πιο εύκολη από ό,τι θα ήταν στο Subversion (επειδή το Git θα ανιχνεύσει αυτόματα την κατάλληλη βάση συγχώνευσης για μας), αυτή δεν είναι μία κανονική υποβολή συγχώνευσης του Git. Πρέπει να ωθήσουμε αυτά τα δεδομένα πίσω σε έναν διακομιστή Subversion που δεν μπορεί να χειριστεί μια υποβολή που παρακολουθεί περισσότερους από έναν γονείς· οπότε, αφού τα ωθήσουμε, θα μοιάζει με μια μία μοναδική υποβολή που στρίμωξε όλη τη δουλειά ενός άλλου κλάδου κάτω από μια και μοναδική υποβολή. Αφού συγχωνεύσουμε έναν κλάδο σε κάποιον άλλο, δεν μπορούμε εύκολα να επιστρέψουμε και να συνεχίσουμε να εργαζόμαστε σε αυτόν τον κλάδο, όπως συνήθως μπορούμε στο Git. Η εντολή dcommit που τρέχουμε διαγράφει κάθε πληροφορία που λέει σε ποιον κλάδο συγχωνεύθηκε, έτσι οι μεταγενέστεροι υπολογισμοί βάσης συγχώνευσης θα είναι λανθασμένοι —η dcommit κάνει το αποτέλεσμα git merge να μοιάζει σαν να τρέξαμε git merge --squash. Δυστυχώς, δεν υπάρχει κάποιος καλός τρόπος για να αποφύγουμε αυτήν την κατάσταση —το Subversion δεν μπορεί να αποθηκεύσει αυτές τις πληροφορίες, έτσι θα είμαστε πάντα πάντα περιορισμένοι από τους περιορισμούς του, εφόσον το χρησιμοποιούμε στον διακομιστή μας. Για να αποφύγουμε τα προβλήματα, πρέπει να διαγράψουμε τον τοπικό κλάδο (στην περίπτωση αυτήν τον opera) αφού τον συγχωνεύσουμε στον κορμό.

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

Τα εργαλεία git svn είναι χρήσιμα αν είμαστε κολλημένοι με έναν διακομιστή Subversion ή βρισκόμαστε σε περιβάλλον ανάπτυξης που απαιτεί τη χρήση διακομιστή Subversion. Θα πρέπει να το δούμε σαν σακατεμένο Git αλλιώς θα συνατήσουμε ζητήματα στη μετάφραση από το ένα σύστημα στο άλλο που μπορεί να μπερδέψουν εμάς και τους συνεργάτες μας. Για να αποφύγουμε τα προβλήματα, καλό είναι να ακολουθούμε αυτές τις οδηγίες:

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

Πρώτα, πρέπει να εγκαταστήσουμε το git-remote-hg. Αυτό ουσιαστικά γίνεται αν απλά αντιγράψουμε το αρχείο κάπου στη διαδρομή μας, όπως παρακάτω:

… με την προϋπόθεση ότι ο ~/bin είναι στο $PATH μας. η git-remote-hg έχει άλλη μία εξάρτηση: τη βιβλιοθήκη Python του Mercurial. Αν έχουμε εγκατεστημένη την Python, αυτό γίνεται πανεύκολα:

(Εάν δεν έχουμε εγκαταστήσει την Python, επισκεφτόμαστε τη διεύθυνση https://www.python.org/ για να την κατεβάσουμε και να την εγκαταστήσουμε.)

Το τελευταίο πράγμα που θα χρειαστούμε είναι ο πελάτης του Mercurial. Μεταβαίνουμε στη διεύθυνση http://mercurial.selenic.com/ και τον εγκαταθιστούμε αν δεν το έχουμε ήδη κάνει.

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

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

Όπως πάντα στο Git, αρχικά κλωνοποιούμε:

Παρατηρούμε ότι η εργασία με ένα αποθετήριο Mercurial χρησιμοποιεί την τυπική εντολή git clone. Αυτό συμβαίνει επειδή το git-remote-hg λειτουργεί σε αρκετά χαμηλό επίπεδο, χρησιμοποιώντας έναν παρόμοιο μηχανισμό με αυτόν που είναι υλοποιημένο το πρωτόκολλο HTTP/S του Git (με απομακρυσμένους βοηθούς). Δεδομένου ότι τα Git και Mercurial έχουν σχεδιαστεί και τα δύο ώστε κάθε πελάτης να έχει ένα πλήρες αντίγραφο του ιστορικού του αποθετηρίου, αυτή η εντολή δημιουργεί έναν πλήρη κλώνο, συμπεριλαμβανομένου ολόκληρου του ιστορικού του έργου και μάλιστα το κάνει αρκετά γρήγορα.

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

Το git-remote-h`g προσπαθεί να κάνει το ιδίωμα πιο Git-οειδές, αλλά εσωτερικά διαχειρίζεται την εννοιολογική απεικόνιση μεταξύ δύο ελαφρώς διαφορετικών συστημάτων. Ο κατάλογος `refs/hg είναι εκεί όπου αποθηκεύονται οι πραγματικές απομακρυσμένες αναφορές. Για παράδειγμα, το αρχείο refs/hg/origin/branches/default είναι ένα αρχείο ref του Git που περιέχει τον SHA-1 που αρχίζει με το ac7955c. Έτσι, ο κατάλογος refs/hg είναι σαν ένα ψεύτικο refs/remotes/origin, αλλά έχει την πρόσθετη διάκριση μεταξύ σελιδοδεικτών και κλάδων.

Το αρχείο notes/hg είναι το σημείο εκκίνησης για τον τρόπο με τον οποίο το git-remote-hg απεικονίζει τους αριθμούς SHA-1 των υποβολών Git σε ID συνόλων αλλαγών του Mercurial. Ας το εξερευνήσουμε αυτό λίγο:

Επομένως, το refs/notes/hg δείχνει σε ένα δέντρο, το οποίο στη βάση δεδομένων αντικειμένων του Git είναι μια λίστα άλλων αντικειμένων με ονόματα. Το git ls-tree εξάγει τα δικαιώματα πρόσβασης, τον τύπο, το hash αντικειμένου και το όνομα αρχείου για τα στοιχεία μέσα σε ένα δέντρο. Μόλις σκάψουμε σε ένα από τα στοιχεία του δέντρου, διαπιστώνουμε ότι μέσα του υπάρχει ένα blob που ονομάζεται ac9117f (ο αριθμός SHA-1 της υποβολής στην οποία δείχνει ο 'master`), με τα περιεχόμενα 0a04b98 (που είναι το αναγνωριστικό του συνόλου αλλαγών του Mercurial στην κορυφή του κλάδου default.

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

Υπάρχει ένα ακόμα πράγμα που πρέπει να εξετάσουμε πριν συνεχίσουμε: τα αγνοεί. Το Mercurial και το Git χρησιμοποιούν έναν πολύ παρόμοιο μηχανισμό για αυτό, αλλά είναι πιθανό ότι δεν θέλουμε πραγματικά να υποβάλουμε ένα αρχείο .gitignore σε ένα αποθετήριο Mercurial. Ευτυχώς, το Git έχει έναν τρόπο να αγνοήσει αρχεία που είναι τοπικά σε ένα αποθετήριο στον δίσκο μας και η μορφή του Mercurial είναι συμβατή με το Git, οπότε απλά πρέπει να το αντιγράψουμε:

Το αρχείο .git/info/exclude λειτουργεί ακριβώς όπως το .gitignore, αλλά δεν περιλαμβάνεται στις υποβολές.

Ας υποθέσουμε ότι έχουμε κάνει κάποια εργασία και κάποιες υποβολές στον κλάδο master και είμαστε έτοιμοι να τις ωθήσουμε στο απομακρυσμένο αποθετήριο. Εδώ φαίνεται το αποθετήριό μας:

Ο κλάδος master προηγείται κατά δύο υποβολές του origin/master, αλλά αυτές οι δύο υποβολές υπάρχουν μόνο στο τοπικό μας μηχάνημα. Ας δούμε αν κάποιος άλλος έχει κάνει σημαντικό έργο την ίδια στιγμή:

Εφόσον χρησιμοποιήσαμε τη σημαία --all, βλέπουμε τις αναφορές “notes” που χρησιμοποιούνται εσωτερικά από το git-remote-hg, αλλά μπορούμε να τις αγνοήσουμε. Τα υπόλοιπα είναι όπως τα αναμέναμε· ο origin/master έχει προχωρήσει κατά μία υποβολή και το ιστορικό μας έχει αποκλίνει τώρα. Σε αντίθεση με τα άλλα συστήματα με τα οποία εργαζόμαστε σε αυτό το κεφάλαιο, το Mercurial είναι ικανό να χειριστεί τις συγχωνεύσεις, οπότε δεν πρόκειται να κάνουμε τίποτα φανταχτερό.

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

Αυτό ήταν! Εάν ρίξουμε μια ματιά στο αποθετήριο Mercurial, θα δούμε ότι έκανε αυτό που αναμέναμε:

Το σύνολο των αλλαγών 2 έγινε από το Mercurial και τα σύνολα αλλαγών 3 και 4 έγιναν από το git-remote-hg, με ώθηση των υποβολών που έγιναν με το Git.

Το Git έχει μόνο ένα είδος κλάδου: μια αναφορά που μετακινείται όταν γίνονται υποβολές. Στο Mercurial, αυτό το είδος μίας αναφοράς ονομάζεται “σελιδοδείκτης” και συμπεριφέρεται με τον ίδιο τρόπο όπως ένας κλάδος Git.

Η αντίληψη του Mercurial περί “κλάδου” είναι πιο βαριά. Ο κλάδος στο οποίο πραγματοποιείται ένα σύνολο αλλαγών καταγράφεται με το σύνολο αλλαγών (changeset), που σημαίνει ότι θα βρίσκεται πάντα στο ιστορικό του αποθετηρίου. Ακολουθεί ένα παράδειγμα υποβολής που έγινε στον κλάδο develop:

Παρατηρούμε τη γραμμή που αρχίζει με branch. Το Git δεν μπορεί να αναπαράγει αυτό το πράγμα (και ούτε χρειάζεται, αφού και οι δύο τύποι κλάδων μπορούν να αναπαρασταθούν ως ref του Git), αλλά το git-remote-hg πρέπει να κατανοήσει τη διαφορά, επειδή το Mercurial πρέπει να ξέρει.

Η δημιουργία των σελιδοδεικτών στο Mercurial είναι τόσο εύκολη όσο και η δημιουργία κλάδων στο Git. Από την πλευρά του Git:

Αυτό ήταν όλο. Από την πλευρά του Mercurial, μοιάζει με αυτό:

Παρατηρούμε τη νέα ετικέτα [featureA] στην αναθεώρηση 5. Αυτά λειτουργούν ακριβώς όπως οι κλάδοι Git στην πλευρά του Git, με μια εξαίρεση: δεν μπορούμε να διαγράψουμε έναν σελιδοδείκτη από την πλευρά του Git (αυτός είναι ένας περιορισμός των απομακρυσμένων βοηθών).

Επίσης μπορούμε να εργαστούμε σε έναν κλάδο “βαρέων βαρών” του Mercurial: απλά βάζουμε έναν κλάδο στον ονοματοχώρο branches:

Ακολουθεί το πώς μοιάζει από την πλευρά του Mercurial:

Το όνομα κλάδου permanent καταγράφηκε με το σύνολο αλλαγών 7.

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

Οι αλλαγές 8, 9 και 10 έχουν δημιουργηθεί και ανήκουν στον κλάδο permanent, αλλά τα παλιά σύνολα αλλαγών είναι ακόμα εκεί. Αυτό μπορεί να επιφέρει πολλή σύγχυση στους συνεργάτες μας που χρησιμοποιούν Mercurial, οπότε προσπαθούμε να το αποφύγουμε.

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

Το Perforce παρέχει ένα προϊόν που ονομάζεται Git Fusion (διαθέσιμο στη http://www.perforce.com/git-fusion), το οποίο συγχρονίζει έναν διακομιστή Perforce με αποθετήρια Git στην πλευρά του διακομιστή.

Η git-p4 είναι μια αμφίδρομη γέφυρα μεταξύ Git και Perforce. Τρέχει εξ ολοκλήρου μέσα στο αποθετήριο Git, επομένως δεν θα χρειαστεί κανενός είδους πρόσβαση στον διακομιστή Perforce (εκτός από τα διαπιστευτήρια χρήστη, φυσικά). Η git-p4 δεν είναι τόσο ευέλικτο ούτε ολοκληρωμένο ως λύση όπως το Git Fusion, αλλά μας επιτρέπει να κάνουμε τα περισσότερα από όσα θέλουμε να κάνουμε χωρίς να επεμβαίνουμε στο περιβάλλον του διακομιστή.

Η git-p4 καθιστά δυνατή τη χρήση μιας ροής εργασίας Git με έναν διακομιστή Perforce και είναι αρκετά καλή σε αυτό. Ωστόσο, είναι σημαντικό να θυμόμαστε ότι το Perforce είναι υπεύθυνο για την πηγή και χρησιμοποιούμε το Git μόνο για να εργαστούμε τοπικά. Απλά ας είμαστε πολύ προσεκτικοί σχετικά με την κοινή χρήση των υποβολών του Git· εάν διαθέτουμε έναν απομακρυσμένο κλάδο στον οποίο μπορούν να δουλεύουν άλλοι χρήστες, πρέπει να μην ωθούμε υποβολές που δεν έχουν ήδη υποβληθεί στον διακομιστή Perforce.

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

Στην πραγματικότητα, υπάρχουν δύο: τα git-tf και git-tfs.

Το git-tfs (που βρίσκεται στη https://github.com/git-tfs/git-tfs) είναι ένα έργο .NET και (τουλάχιστον τώρα που γράφεται αυτό το κείμενο) τρέχει μόνο σε Windows. Για να συνεργαστεί με αποθετήρια Git, χρησιμοποιεί συνδέσεις της .NET για libgit2, μια εφαρμογή του Git που προσανατολίζεται στη βιβλιοθήκη, η οποία είναι εξαιρετικά αποδοτική και επιτρέπει μεγάλη ευελιξία με τις εσωτερικές λειτουργίες ενός αποθετηρίου Git. Το Libgit2 δεν είναι μια ολοκληρωμένη εφαρμογή του Git, οπότε για να καλύψει τη διαφορά, το git-tfs καλεί τη γραμμής εντολών του πελάτη Git για κάποιες λειτουργίες κι έτσι δεν υπάρχουν τεχνητά όρια στο τι μπορεί να κάνει με τα αποθετήρια Git. Η υποστήριξη των χαρακτηριστικών του TFVC είναι πολύ ώριμη, αφού χρησιμοποιεί τα συγκροτήσεις Visual Studio για εργασίες με διακομιστές. Αυτό σημαίνει ότι θα χρειαστούμε πρόσβαση σε αυτές τις συγκροτήσεις, πράγμα που σημαίνει ότι πρέπει να εγκαταστήσουμε μια πρόσφατη έκδοση του Visual Studio (οποιαδήποτε έκδοση από την έκδοση 2010 και μετά, συμπεριλαμβανομένης της Express από την έκδοση 2012) ή το Visual Studio SDK.

Το git-tf (του οποίου το σπίτι βρίσκεται στη https://gittf.codeplex.com) είναι ένα έργο Java και ως εκ τούτου τρέχει σε οποιονδήποτε υπολογιστή με περιβάλλον εκτέλεσης Java (Java runtime environment). Συνδέεται με τα αποθετήρια Git μέσω του JGit (εφαρμογή JVM του Git), πράγμα που σημαίνει ότι δεν έχει ουσιαστικά κανένα περιορισμό όσον αφορά τις λειτουργίες του Git. Ωστόσο, η υποστήριξή του για το TFVC είναι περιορισμένη σε σύγκριση με το git-tfs —για παράδειγμα, δεν υποστηρίζει κλάδους.

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

Το πρώτο πράγμα που κάνουμε, όπως συμβαίνει με οποιοδήποτε πρόγραμμα Git, είναι ο κλώνος. Με το git-tf αυτό μοιάζει ως εξής:

Το πρώτο όρισμα είναι η διεύθυνση URL μιας συλλογής TFVC, η δεύτερη είναι της μορφής $/έργο/κλάδος και η τρίτη είναι η διαδρομή προς τον τοπικό αποθετήριο Git που πρόκειται να δημιουργηθεί (το τελευταίο είναι προαιρετικό). Το git-tf μπορεί να λειτουργήσει μόνο με έναν κλάδο κάθε φορά· εάν θέλουμε να κάνουμε checkin σε διαφορετικό κλάδο TFVC, θα πρέπει να κάνουμε έναν νέο κλώνο από αυτόν τον κλάδο.

Αυτό δημιουργεί ένα πλήρως λειτουργικό αποθετήριο Git:

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

Αν έχουμε κάποιο χρόνο, αξίζει τον κόπο να κλωνοποιήσουμε ολόκληρο το ιστορικό του έργου, χρησιμοποιώντας την επιλογή --deep:

Παρατηρούμε ετικέτες με ονόματα όπως TFS_C35189· αυτό είναι ένα χαρακτηριστικό που μας βοηθάει να ξέρουμε ποιες υποβολές του Git σχετίζονται με το σύνολο αλλαγών του TFVC. Αυτός είναι ένας καλός τρόπος αναπαράστασης, αφού μπορούμε να δούμε με μια απλή εντολή log ποια από τις υποβολές μας σχετίζεται με ένα στιγμιότυπο που υπάρχει επίσης στο TFVC. Δεν είναι απαραίτητες (στην πραγματικότητα μπορούμε να τις απενεργοποιήσουμε με την git config git-tf.tag false) —η git-tf διατηρεί τις πραγματικές αντιστοιχίσεις υποβολών-συνόλων αλλαγών στο αρχείο .git/git-tf.

Η κλωνοποίηση του git-tfs συμπεριφέρεται λίγο διαφορετικά:

Παρατηρούμε τη σημαία --with-branches. Το git-tfs είναι ικανό να απεικονίσει κλάδους TFVC σε κλάδους Git και αυτή η σημαία του λέει να δημιουργήσει έναν τοπικό κλάδο Git για κάθε κλάδο TFVC. Αυτό συνιστάται ιδιαίτερα αν έχουμε διακλαδιστεί ή συγχωνευτεί στο TFS, αλλά δεν θα λειτουργήσει με διακομιστές παλαιότερους από τον TFS 2010 —πριν από αυτήν την έκδοση, οι “κλάδοι” ήταν απλά κατάλογοι, οπότε το git-tfs δεν μπορεί να τους ξεχωρίσει από τους κανονικούς καταλόγους.

Ας ρίξουμε μια ματιά στο αποθετήριο Git που προκύπτει:

Υπάρχουν δύο τοπικοί κλάδοι, master και featureA, που αναπαριστούν το αρχικό σημείο εκκίνησης του κλώνου (Trunk στο TFVC) και έναν κλάδο-απόγονο (featureA στο TFVC). Μπορούμε επίσης να δούμε ότι το “απομακρυσμένο αποθετήριο” του tfs έχει επίσης μερικά refs: default και featureA, που αναπαριστούν κλάδους του TFVC. Το git-tfs απεικονίζει τον κλάδο που έχουμε κλωνοποιήσει από το tfs/default, και οι άλλοι παίρνουν τα δικά τους ονόματα.

Ένα άλλο πράγμα που πρέπει να παρατηρήσουμε είναι οι γραμμές git-tfs-id: στα μηνύματα υποβολών. Αντί των ετικετών, το git-tfs χρησιμοποιεί αυτά τα σημάδια για να συνδέσει τα σύνολα αλλαγών του TFVC με τις υποβολές Git. Αυτό έχει ως συνέπεια ότι οι υποβολές μας θα έχουν διαφορετικό αριθμο SHA-1 πριν και μετά την ώθησή τους στο TFVC.

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

Χάρη συντομίας, αυτό που θα καλύψουμε εδώ είναι το βατό μονοπάτι, το οποίο παρακάμπτει ή αποφεύγει τα περισσότερα από αυτά τα προβλήματα.

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

Θέλουμε να πάρουμε το στιγμιότυπο που βρίσκεται στην 4178a82 και να το ωθήσουμε στον διακομιστή TFVC. Καταρχάς ας δούμε αν οποιοσδήποτε από τους συμπαίκτες μας έκανε κάτι από τότε που συνδεθήκαμε τελευταία φορά:

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

Η επιλογή είναι δική μας. Σε αυτό το παράδειγμα, θα κάνουμε αλλαγή βάσης:

Τώρα είμαστε έτοιμοι να κάνουμε checkin στον διακομιστή TFVC. Το git-tf μας δίνει τις εξής επιλογές: να δημιουργήσουμε ένα ενιαίο σύνολο αλλαγών που αναπαριστά όλες τις αλλαγές από την τελευταία checkin (--shallow, που είναι και η προεπιλογή) ή να δημιουργήσουμε ένα νέο σύνολο αλλαγών για κάθε υποβολή Git (--deep). Σε αυτό το παράδειγμα, θα δημιουργήσουμε μόνο ένα σύνολο αλλαγών:

Υπάρχει μια νέα ετικέτα TFS_C35348, που υποδεικνύει ότι το TFVC αποθηκεύει ακριβώς το ίδιο στιγμιότυπο με την υποβολή 5a0e25e. Είναι σημαντικό να σημειώσουμε ότι δεν είναι απαραίτητο κάθε υποβολή Git να έχει ένα ακριβές αντίγραφο στο TFVC· η υποβολή 6eb3eb5, για παράδειγμα, δεν υπάρχει σε κανένα σημείο του διακομιστή.

Αυτή είναι η κύρια ροή εργασίας. Υπάρχουν μερικά άλλα θέματα που πρέπει να έχουμε κατά νου:

Ας περάσουμε από το ίδιο σενάριο χρησιμοποιώντας το git-tfs. Ακολουθούν οι νέες υποβολές που έχουμε κάνει στον κλάδο master στο αποθετήριο Git:

Τώρα ας δούμε αν κάποιος άλλος έχει κάνει δουλειά ενώ εμείς κάναμε τις δικές μας αλλαγές:

Ναι, αποδεικνύεται ότι ο συνεργάτης μας έχει προσθέσει ένα νέο σύνολο αλλαγών TFVC, το οποίο εμφανίζεται με τη νέα υποβολή aea74a0 και ο απομακρυσμένος κλάδος tfs/default μετακινήθηκε.

Όπως και με το git-tf, έχουμε δύο βασικές επιλογές για τον τρόπο επίλυσης αυτού του αποκλίνοντος ιστορικού:

Σε αυτήν την περίπτωση, θα κάνουμε ένα “βαθύ” checkin, στο οποίο κάθε υποβολή Git θα γίνει ένα σύνολο αλλαγών TFVC, οπότε θέλουμε να αλλάξουμε τη βάση.

Τώρα είμαστε έτοιμοι να ολοκληρώσουμε τη συνεισφορά μας ελέγχοντας τον κώδικά μας στον διακομιστή TFVC. Θα χρησιμοποιήσουμε την εντολή rcheckin για να δημιουργήσουμε ένα σύνολο αλλαγών TFVC για κάθε υποβολή Git στη διαδρομή από τον HEAD στον πρώτο απομακρυσμένο κλάδο tfs που βρέθηκε (η εντολή checkin θα δημιουργούσε μόνο ένα σύνολο αλλαγών, όπως η συναρμογή υποβολών στο Git).

Παρατηρούμε πως μετά από κάθε επιτυχές checkin στον διακομιστή TFVC, το git-tfs αλλάζει τη βάση του υπόλοιπου έργου σε αυτό που μόλις έκανε. Αυτό συμβαίνει επειδή προσθέτει το πεδίο git-tfs-id στο κάτω μέρος των μηνυμάτων υποβολής, το οποίο αλλάζει τους αριθμούς SHA-1. Αυτό είναι ακριβώς όπως έχει σχεδιαστεί και δεν υπάρχει κάτι να μας ανησυχεί, αλλά θα πρέπει να γνωρίζουμε ότι συμβαίνει αυτό, ειδικά αν μοιραζόμαστε υποβολές Git με άλλους.

Το TFS έχει πολλές λειτουργίες που ενσωματώνονται με το σύστημα ελέγχου εκδόσεών του, όπως στοιχεία εργασίας, ορισθέντες αναθεωρητές, φραγμένα checkin κ.ο.κ. Η εργασία με αυτά τα χαρακτηριστικά χρησιμοποιώντας μόνο το εργαλείο γραμμής εντολών μπορεί να είναι δύσχρηστη, αλλά ευτυχώς το git-tfs μας επιτρέπει να ξεκινήσουμε ένα γραφικό εργαλείο checkin (checkintool) πολύ εύκολα:

Μοιάζει λίγο σαν αυτό:

Αυτό είναι οικείο στους χρήστες του TFS, καθώς είναι ο ίδιος διάλογος που ξεκινάει μέσα από το Visual Studio.

Το git-tfs μας επιτρέπει επίσης να ελέγχουμε τους κλάδους του TFVC από το αποθετήριο Git. Για παράδειγμα, ας δημιουργήσουμε ένα:

Η δημιουργία ενός κλάδου στο TFVC σημαίνει την προσθήκη ενός συνόλου αλλαγών όπου αυτό υπάρχει αυτός ο κλάδος αυτήν τη στιγμή και αυτό προβάλλεται ως υποβολή Git. Ας σημειωθεί επίσης ότι το git-tfs δημιούργησε τον απομακρυσμένο κλάδο tfs/featureBee, αλλά ο HEAD εξακολουθεί να δείχνει στον master. Εάν θέλουμε να εργαστούμε στον νεοσύστατο κλάδο, θα θελήσουμε να βασίσουμε τις νέες υποβολές μας στην υποβολή 1d54865, ίσως δημιουργώντας έναν θεματικό κλάδο από αυτήν την υποβολή.

Τα git-tf και git-tfs είναι και τα δύο εξαιρετικά εργαλεία για τη διασύνδεση με έναν διακομιστή TFVC. Μας επιτρέπουν να χρησιμοποιούμε τη δύναμη του Git τοπικά, να αποφεύγουμε να ταξιδεύουμε συνεχώς στον κεντρικό διακομιστή TFVC και να κάνουν τη ζωή μας ως προγραμματιστών πολύ πιο εύκολη, χωρίς να αναγκάζουν ολόκληρη την ομάδα μας να μεταναστεύσει στο Git. Εάν εργαζόμαστε σε Windows (που είναι και το πιο πιθανό, εφόσον η ομάδα μας χρησιμοποιεί το TFS), πιθανότατα θέλουμε να χρησιμοποιούμε το git-tfs, καθώς το σύνολο χαρακτηριστικών του είναι πιο πλήρες, αλλά αν εργαζόμαστε σε άλλη πλατφόρμα, θα θέλαμε να χρησιμοποιούμε το Γιτ-tf, το οποίο είναι πιο περιορισμένο. Όπως συμβαίνει με τα περισσότερα εργαλεία αυτού του κεφαλαίου, θα πρέπει να επιλέξουμε ένα από αυτά τα συστήματα ελέγχου εκδόσεων να είναι κανονικό (canonical) και να χρησιμοποιήσουμε το άλλο με δευτερεύοντα τρόπο —είτε το Git είτε το TFVC θα πρέπει να είναι το κέντρο συνεργασίας, αλλά όχι και τα δύο.