Περιεχόμενο
- Η άνοδος του Git
- Έμφυτοι κίνδυνοι με το Git Merges
- Ο άνθρωπος πίσω από την κουρτίνα: Πώς λειτουργεί το Git;
- Παράδειγμα: Συγχώνευση δεσμεύσεων
- Συγχώνευση συγκρούσεων
- Τι συμβαίνει στη συγχώνευση
- Ο καρχαρίας στο νερό: Βοηθά ή βλάπτει το Git;
- Παράδειγμα 2: Λάθη στη συγχώνευση
- Ένα δύσκολο να βρεθεί σφάλμα
- The Takeaway: Προβλήματα με κλάδους
- Ανάπτυξη βάσει κορμού
- Οφέλη
- Το πρόβλημα δεν είναι Git. Είναι το πώς το χρησιμοποιούμε
Ο Mike Shoemake είναι επιτυχημένος προγραμματιστής λογισμικού εδώ και 20 χρόνια, δημιουργώντας εφαρμογές ποιότητας και ομάδες ανάπτυξης υψηλής απόδοσης.
Η άνοδος του Git
Το Git φαίνεται να αναλαμβάνει τον κόσμο, όσον αφορά τα Συστήματα Ελέγχου Έκδοσης. Πριν από δέκα χρόνια, ήταν το Subversion που είχε τραβήξει το ενδιαφέρον μας (η κόκκινη γραμμή παρακάτω). Τώρα το Git (η μπλε γραμμή) ελέγχεται σταθερά.
Ακόμα, υπάρχουν πολλά να μάθουμε με το Git. Πολλοί από εμάς ήρθαμε στο Git αφού περάσαμε πολύ χρόνο με το Subversion ή κάποιον άλλο ανταγωνιστή και ο τρόπος που χρησιμοποιούμε το Git αντικατοπτρίζει τώρα την εμπειρία μας και την κατανόηση αυτών των άλλων εργαλείων. Μάθαμε αρκετά για να επιβιώσουμε και επιστρέψαμε γρήγορα στις καθημερινές μας δουλειές.
Αλλά το Git είναι πολύ, πολύ διαφορετικό από οποιοδήποτε άλλο σύστημα ελέγχου έκδοσης που μπορεί να έχετε χρησιμοποιήσει. Εάν καταλαβαίνετε το Git, είναι ο καλύτερος φίλος σας. Εάν δεν το κάνετε, μπορείτε να το χρησιμοποιήσετε με τρόπο που δημιουργεί περιττό κίνδυνο για εσάς και την ομάδα σας. Παραδόξως, τα προβλήματα παραγωγής θα μπορούσαν να προκύψουν από τη χρήση του Git με τρόπο που δεν προοριζόταν να χρησιμοποιηθεί.
Έμφυτοι κίνδυνοι με το Git Merges
Όπως θα δούμε, οι συγχωνεύσεις Git έχουν εγγενή κίνδυνο που σχετίζονται με αυτούς πέρα από τους προγραμματιστές που κάνουν ένα χάος της επίλυσης συγκρούσεων. Αυτός ο κίνδυνος αυξάνεται δραματικά όσο περισσότερο περιμένουμε να ενσωματώσουμε τον κωδικό μας. Αποδεικνύεται ότι οι μεγάλες συγχωνεύσεις είναι πολύ πιο επικίνδυνες από τις μικρές, αλλά πολλές ομάδες ανάπτυξης κάνουν μεγάλες συγχωνεύσεις ως τρόπο ζωής. Το μοντέλο διακλάδωσης μπορεί να επηρεάζει αρνητικά την ποιότητα στην παραγωγή και απλά δεν το γνωρίζετε ακόμη.
Ας ρίξουμε μια πρώτη ματιά στον τρόπο λειτουργίας του Git συγχωνεύσεων και, στη συνέχεια, μπορούμε να προσδιορίσουμε τον καλύτερο τρόπο χρήσης τους. Στα παρακάτω παραδείγματα, θα χρησιμοποιήσουμε το SourceTree για να μας βοηθήσουμε να απεικονίσουμε τι συμβαίνει.
Ο άνθρωπος πίσω από την κουρτίνα: Πώς λειτουργεί το Git;
Μπορείτε να σκεφτείτε τις συγχωνεύσεις Git όπως ανακατέψτε μια τράπουλα. Το Git παίρνει δύο ξεχωριστές τράπουλες και τα υφαίνει μαζί σε μία τράπουλα, πετώντας επιπλέον όταν βρεθούν διπλότυπα.
Παράδειγμα: Συγχώνευση δεσμεύσεων
Εξετάστε το παρακάτω παράδειγμα:
Αυτό είναι ένα απλό αρχείο κατηγορίας Groovy που δεν κάνει τίποτα άλλο παρά να κάνει κλήσεις println (). Τώρα δύο προγραμματιστές, ο Τζιμ και ο Φρεντ, το καθένα τροποποίησαν αυτό το αρχείο ταυτόχρονα, κάτι που θα απαιτήσει συγχώνευση για επίλυση.
Καθένας έχει δημιουργήσει έναν κλάδο, που είναι απλώς ένα όνομα στο οποίο μπορεί να συσχετιστεί μια σειρά δεσμεύσεων. Ο κλάδος (δηλ. Το όνομα) σχετίζεται άμεσα με την πιο πρόσφατη δέσμευση, οπότε όταν γίνεται μια νέα δέσμευση, το όνομα του κλάδου μετακινείται στο νέο. Κάθε δέσμευση επιστρέφει στον προκάτοχό της - δεν δείχνουν ποτέ μπροστά.
Ακολουθεί η δέσμευση του Jim:
Παρατηρήστε ότι ο Jim επεξεργάστηκε τη γραμμή 21 για να προσθέσει ένα σχόλιο και ο Git το βλέπει ως μια συνεχόμενη αλλαγή που περιλαμβάνει μια κατάργηση και μια προσθήκη.
Και εδώ είναι ο Fred:
Αυτό που είναι σημαντικό είναι ότι υπάρχουν πολλές ξεχωριστές αλλαγές εδώ - μερικές που αλληλεπικαλύπτονται και μερικές που απέχουν μόνο μία γραμμή.
Για να λάβουμε μια προεπισκόπηση της συγχώνευσης, μπορούμε να επισημάνουμε και τις δύο δεσμεύσεις στο SourceTree, να κάνουμε κλικ στο αρχείο προέλευσης και να δούμε την προκύπτουσα διαφορά.
Με την επιλογή και των δύο δεσμεύσεων, βλέπουμε τη διαφορά παρακάτω:
Συγχώνευση συγκρούσεων
Το Git αναγνωρίζει διακριτές αλλαγές, καθεμία από τις οποίες είναι συνεχόμενη ομάδα γραμμών που έχουν αλλάξει. Το Git θα προσπαθήσει να υφαίνει μαζί τα αλλαγμένα μπλοκ με τα αμετάβλητα μπλοκ. Εάν δύο αλλαγμένα μπλοκ δεν έχουν τουλάχιστον μία αμετάβλητη γραμμή μεταξύ τους, ο Git θεωρεί ότι πρόκειται για σύγκρουση συγχώνευσης.
Σε αυτό το παράδειγμα, μπορούμε ήδη να δούμε πού θα βρίσκονται οι συγκρούσεις συγχώνευσης:
- γραμμή 5
- γραμμή 21
Επειδή οι κόκκινες και πράσινες αλλαγές "αγγίζουν" στη διαφορά, το Git δεν θα ξέρει ποιο θα βάλει στην κορυφή. Έτσι, επισημαίνει αυτές τις αλλαγές ως συγχώνευση συγκρούσεων και ζητά από τον προγραμματιστή να το καταλάβει. Δεδομένου ότι οι άλλες αλλαγές διαχωρίζονται από κοινές γραμμές κώδικα, υπάρχει μια σαφής σειρά για να ακολουθήσει το Git. Από την οπτική γωνία του Git, είναι όλα σχετικά με το πώς να πλένουμε τα πράγματα μαζί και να βεβαιωθούμε ότι έχει γίνει με τη σωστή σειρά. Εάν ο Git δεν είναι σίγουρος, σας ζητά να το επιλύσετε μόνοι σας.
Τι συμβαίνει στη συγχώνευση
Εδώ είναι το αποτέλεσμα της πραγματικής συγχώνευσης:
Όπως μπορείτε να δείτε, οι συγκρούσεις συγχώνευσης εμφανίστηκαν εκεί που αναμενόταν. Οι γραμμές 29 και 30 θεωρούνται μια συνεχόμενη αλλαγή και έτσι συμπεριλαμβάνονται στη σύγκρουση συγχώνευσης. Επειδή οι άλλες αλλαγές δεν αλληλεπικαλύπτονται, το Git είναι σε θέση να προσδιορίσει τη σωστή σειρά και τα υπόλοιπα για εσάς.
Ο καρχαρίας στο νερό: Βοηθά ή βλάπτει το Git;
Το Git είναι σίγουρα χρήσιμο με την επίλυση συγκρούσεων για εμάς. Οι προγραμματιστές λατρεύουν αυτήν τη δυνατότητα! Πολλοί από εμάς στηριζόμαστε στη δυνατότητα αυτόματης συγχώνευσης του Git σαν το Git να είναι ένα φουτουριστικό Android με τρελές δεξιότητες κωδικοποίησης που φροντίζει την ελαφριά δουλειά μας, ώστε να μην χρειάζεται να το ιδρώνουμε. Και όμως, ο Git δεν γνωρίζει τίποτα για το πλαίσιο. Δεν κάνει σημασιολογική ανάλυση και δεν έχει κανέναν τρόπο να καθορίσει εάν οι αλλαγές από δύο συγχωνευμένα αρχεία προέλευσης ανήκουν στην πραγματικότητα ή είναι αμοιβαία αποκλειστικές.
Παράδειγμα 2: Λάθη στη συγχώνευση
Εξετάστε το παρακάτω παράδειγμα:
Αυτό είναι ένα πολύ απλό αρχείο προέλευσης Groovy με μια μέθοδο multiply (int, int) και μια κύρια μέθοδο που καλεί multiply (). Αυτός είναι στην πραγματικότητα ο κώδικας που βρίσκεται στην κορυφή του κύριου κλάδου παρακάτω.
Ο Fred πρόσθεσε μια νέα κλήση στη μέθοδο multiply ():
Σε αντίθεση με τον Φρεντ, ο Τζιμ αποφάσισε να αποσύρει τη μέθοδο πολλαπλασιασμού, αφαιρώντας την και τη μέθοδο κλήσεων που εξαρτώνται από αυτήν.
Το τελικό αποτέλεσμα της συγχώνευσης (φαίνεται παρακάτω) περιλαμβάνει μια κλήση στη μέθοδο multiply (), αλλά τώρα αυτή η μέθοδος δεν υπάρχει πλέον.
Ένα δύσκολο να βρεθεί σφάλμα
Ακόμα χειρότερα, αυτός ο κώδικας καταρτίζεται επειδή είναι Groovy και όχι Java. Έτσι, ο μόνος τρόπος για να γνωρίζετε ότι υπάρχει αυτό το πρόβλημα είναι να εντοπίσετε μια εξαίρεση στο χρόνο εκτέλεσης. Εάν ο χειρισμός σφαλμάτων σας δεν είναι εξαιρετικός, ενδέχεται να δυσκολευτείτε να παρακολουθήσετε αυτό το ζήτημα και να μην συνειδητοποιήσετε ποτέ ότι προκλήθηκε από την αυτόματη συγχώνευση του Git.
Οι δυναμικές γλώσσες (π.χ. Groovy, Javascript, Python, Ruby, πολλές άλλες) είναι ιδιαίτερα επιρρεπείς σε αυτό το ζήτημα λόγω περιορισμένου χρόνου μεταγλώττισης. Ενώ η σταθερή κάλυψη δοκιμών μονάδας / ενοποίησης είναι σίγουρα χρήσιμη για τον εντοπισμό ζητημάτων που μπορεί να προκύψουν από αυτό, οι ομάδες συχνά δεν έχουν την απαιτούμενη κάλυψη για την προστασία τους από βλάβες.
Ενώ τις περισσότερες φορές το Git κάνει μια καλή δουλειά για την επίλυση διενέξεων για εσάς, υπάρχει η ευκαιρία να συμβούν λάθη. Αν το συνδυάσετε με περιπτώσεις προγραμματιστών που χειρίζονται λανθασμένες συγχωνεύσεις, οι συγχωνεύσεις Git έχουν σίγουρα κίνδυνο να σχετίζονται με αυτές. Πώς λοιπόν μετριάζουμε αυτόν τον κίνδυνο;
The Takeaway: Προβλήματα με κλάδους
Πολλές ομάδες ανάπτυξης έχουν υιοθετήσει κλάδους χαρακτηριστικών ως αναπόσπαστο μέρος του μοντέλου διακλάδωσης. Οι κλάδοι χαρακτηριστικών είναι πολίτης πρώτης κατηγορίας του δημοφιλούς "GitFlow", και πολλοί οργανισμοί έχουν δημιουργήσει προσαρμοσμένα μοντέλα διακλάδωσης που βασίζονται σε μεγάλο βαθμό στους κλάδους χαρακτηριστικών. Οι κλάδοι λειτουργιών επιτρέπουν σε μεμονωμένους προγραμματιστές να εργάζονται μεμονωμένα έως ότου ολοκληρωθεί η λειτουργία τους, οπότε δεν θα πρέπει να επηρεαστούν αρνητικά από τις αλλαγές κάποιου άλλου. Ορισμένοι οργανισμοί φτάνουν στο σημείο να χρησιμοποιούν μακροχρόνια υποκαταστήματα για να απομονώσουν ολόκληρες ομάδες όταν πολλές ομάδες εργάζονται στην ίδια βάση κώδικα. Άλλοι τα χρησιμοποιούν για να απομονώσουν πολλές κυκλοφορίες που δημιουργούνται ταυτόχρονα.
Τελικά, όλα αυτά τα πράγματα που είναι ενσωματωμένα σε απομόνωση πρέπει να συγχωνευτούν για να τα οδηγήσουν στην παραγωγή και εκεί εμφανίζεται ο κίνδυνος. Όταν δύο κλάδοι συγχωνεύονται μεταξύ τους και ο καθένας έχει μεγάλες αλλαγές, είναι σχεδόν αδύνατο να γνωρίζουμε με βεβαιότητα ότι, μεταξύ του Git και της χειροκίνητης επίλυσης συγκρούσεων, κάθε κατάσταση αντιμετωπίστηκε σωστά. Και πάλι, ο Git δεν γνωρίζει τίποτα για το περιεχόμενο, τον σκοπό ή τη σημασιολογία. Σκέφτεται μόνο για την τάξη.
Οι προγραμματιστές διδάσκονται ότι οι κλάδοι λειτουργιών μεγάλης διάρκειας είναι εντάξει, αρκεί να συγχωνεύετε περιοδικά νέες αλλαγές στον κλάδο προορισμού (ο προορισμός για την επερχόμενη συγχώνευση) στον κλάδο λειτουργιών. Αυτό υποτίθεται ότι θα σας κρατήσει σε επαφή με όλους τους άλλους. Δυστυχώς, αυτό είναι ένας αντικατοπτρισμός. Εάν 5 προγραμματιστές σε μια ομάδα εργάζονται όλοι σε ξεχωριστούς κλάδους λειτουργιών για κάποιο χρονικό διάστημα, δεν έχει σημασία πόσο συχνά συγχωνεύουν το υποκατάστημα στόχο στους αντίστοιχους κλάδους τους. Δεν είναι ακόμη ενσωματωμένοι. Παρουσιάστηκε σημαντική αλλαγή που δεν είναι ορατή σε κανέναν επειδή οι άνθρωποι δεν είναι ακόμη έτοιμοι να συγχωνευτούν.
Τι γίνεται αν δεν είναι 5 προγραμματιστές αλλά 25 ή 75, όλοι εργάζονται στην ίδια βάση κώδικα; Αυτές οι συγχωνεύσεις πραγματοποιούνται κοντά στο τέλος του σπριντ, και είναι πολύ χρονοβόρα για να επαληθευτεί ότι τα πάντα αντιμετωπίστηκαν σωστά. Η καθυστερημένη ενσωμάτωση δημιουργεί πάντα περιττό κίνδυνο και συχνά το θέτει ακριβώς όταν το θέλετε λιγότερο - όταν ολοκληρώνετε ένα σπριντ ή μια κυκλοφορία.
Ανάπτυξη βάσει κορμού
Τώρα ας εξετάσουμε την ανάπτυξη με βάση τον κορμό, η οποία ζητά από τους προγραμματιστές να ωθήσουν μικρές, καλά δοκιμασμένες δεσμεύσεις καθημερινά, αν όχι αρκετές φορές την ημέρα, σε έναν κοινό κλάδο κορμού που συνήθως ονομάζεται "master". Οι κλάδοι συντήρησης δημιουργούνται καθώς βγαίνουν οι κυκλοφορίες, αλλά όλες οι νέες εξελίξεις μεταφέρονται απευθείας στον κύριο κλάδο.
Τα μεγάλα χαρακτηριστικά κατανέμονται σε μικρά κομμάτια μεγέθους δαγκώματος και οι προγραμματιστές χρησιμοποιούν εναλλαγή λειτουργιών για να αποκρύψουν τις αλλαγές τους έως ότου έρθει η ώρα να μεταδοθούν ζωντανά. Πρόκειται για μια πραγματική συνεχή ολοκλήρωση, η οποία έχει πολλές σημαντικές επιπτώσεις για εμάς:
- Δεν υπάρχουν κλάδοι χαρακτηριστικών, επομένως κάθε προγραμματιστής δημιουργεί τον σημερινό κώδικα πάνω από τον κώδικα όλων από το χθες.
- Χωρίς συγχώνευση υποκαταστημάτων - απλώς δεσμεύστε και προωθήστε τις αλλαγές στους κλάδους κορμού και συντήρησης.
- Τα σφάλματα που προορίζονται για έναν κλάδο συντήρησης καθορίζονται πάντα στον κορμό πρώτα και στη συνέχεια το κεράσι μαζεύεται στον κλάδο συντήρησης (για την αποφυγή προβλημάτων παλινδρόμησης).
Οφέλη
- Η ευκαιρία για συγχώνευση συγκρούσεων μειώνεται δραστικά. Λιγότερος κώδικας έχει αλλάξει, έτσι έχουμε λίγες ευκαιρίες για σύγκρουση.
- Η συχνή δέσμευση στους προγραμματιστές αναγκών κορμού να σκεφτεί την ποιότητα καθ 'όλη τη διάρκεια του κύκλου κατασκευής αντί να τη σώσει μέχρι το τέλος (μικρή αλλαγή, δοκιμή, ώθηση, μικρή αλλαγή, δοκιμή, ώθηση).
- Οι συγκρούσεις εντοπίζονται νωρίς κατά τη διάρκεια της κατασκευής, και όχι αργά στο χρόνο συγχώνευσης.
- Η συνεχής ενσωμάτωση δημιουργεί ένα πραγματικό παράθυρο στην τρέχουσα κατάσταση του κώδικα, την κυκλοφορία κ.λπ. Τίποτα δεν κρύβεται στις σκιές.
Η καθυστερημένη ενοποίηση μπορεί επίσης να σας αναγκάσει να σταθεροποιήσετε τον ίδιο κώδικα πολλές φορές. Για παράδειγμα, ορισμένες ομάδες κάνουν δοκιμές και σταθεροποίηση χαρακτηριστικών στον κλάδο χαρακτηριστικών, ώστε να μπορούν να δοκιμαστούν μεμονωμένα. Μόλις γίνει η συγχώνευση, είναι πολύ πιθανό ότι η λειτουργία έχει αποσταθεροποιηθεί και τώρα πρέπει να περάσετε από αυτήν τη διαδικασία ξανά. Ή μπορείτε να υποθέσετε ότι είναι σταθερό δεδομένου ότι δούλευε στον κλάδο χαρακτηριστικών και απλώς αφήστε το να βγει από την πόρτα με αυτόν τον τρόπο. Όλα αυτά θα μπορούσαν να αποφευχθούν εάν απλώς ενσωματωθούμε νωρίς.
Το πρόβλημα δεν είναι Git. Είναι το πώς το χρησιμοποιούμε
Το Git έχει πολλά φανταστικά χαρακτηριστικά. Η δυνατότητα συγχώνευσης είναι το κεφάλι και οι ώμοι πάνω από αυτό που παρέχεται από τους ανταγωνιστές της Git. Όσοι από εμάς το έχουμε χρησιμοποιήσει όλοι είδαμε ότι το Git συγχωνεύεται με επιτυχία χωρίς τη βοήθειά μας, κάτι που μπορεί να μας ξεγελάσει σε μια ψευδή αίσθηση ασφάλειας. Το πρόβλημα δεν είναι καθόλου το Git. Είναι πώς το χρησιμοποιούμε. Το σοφότερο πράγμα που μπορούμε να κάνουμε είναι να καταβάλουμε προσπάθειες για να καταλάβουμε τι είναι το εργαλείο και τι δεν είναι. Μόλις το κάνουμε αυτό, μπορούμε να το χρησιμοποιήσουμε με τον τρόπο που προοριζόταν και να σταματήσουμε να βλάπτουμε τον εαυτό μας με αυτό.
Αυτό το άρθρο είναι ακριβές και πιστό από ό, τι γνωρίζουν οι συγγραφείς. Το περιεχόμενο προορίζεται μόνο για ενημερωτικούς ή ψυχαγωγικούς σκοπούς και δεν υποκαθιστά προσωπικές συμβουλές ή επαγγελματικές συμβουλές σε επιχειρηματικά, οικονομικά, νομικά ή τεχνικά θέματα.
