Πώς οι βέλτιστες πρακτικές της Git μου έσωσαν ώρες επανεπεξεργασίας

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

Η εφαρμογή είναι παλιά. Οι μονάδες Core-NodeJS-Infra δεν έχουν ενημερωθεί για περισσότερο από δύο χρόνια. Οι κατάντη υπηρεσίες έχουν καταργηθεί. Ο τρόπος που ονομάζουμε μεταγενέστερες υπηρεσίες αλλάζει. Η σφιχτή προθεσμία είναι ένα κεράσι στην τούρτα. Ήξερα ότι θα ήταν μια διαδρομή με ρόλερ.

Πέρασα τρεις μέρες για να τρέξω το app.

Οι υποδομές ενημερώνονται; Ελεγχος.

Οι μεταγενέστερες υπηρεσίες λειτουργούν σωστά; Ελεγχος.

Οι ροές UI λειτουργούν καλά; Ελεγχος.

Ένα από τα μέλη της ομάδας μας είχε αγγίξει την εφαρμογή για αναβάθμιση πριν από ένα χρόνο. Υπογράμμισε ότι το repo από το σημείο που διέθεσα ήταν το ίδιο ένα διχαλωτό repo. Κάποια άλλη ομάδα είχε δουλέψει σε αυτό το repo και στη συνέχεια η ομάδα μας εργάστηκε στο αρχικό repo από εκεί και πέρα ​​- αλλά το μέλος της ομάδας μου δεν ξέρει από πού και πότε. Γι 'αυτό ήταν λίγο ένα χάος!

Έχουμε ένα εργαλείο "Ιδιοκτησίας" το οποίο δείχνει το σωστό repo και "ψέμασε" σε μένα. Έτσι η κατάσταση ήταν έτσι:

Περονοφόρα

Ναι, ήταν Forkception! Το WTF και το FML ήταν οι πρώτες δύο σκέψεις που βγήκαν από το στόμα μου. Θα έπρεπε να είχα εργαστεί στο live repo, αλλά, αντ 'αυτού, δούλευα σε μια διχαλωτή περόνη. Πόσο ανόητο από μένα!

Πρώτη σκέψη - οι τρεις μέρες δουλειάς μου έχουν χαθεί και πρέπει να ξεκινήσω φρέσκο.

Δεύτερη σκέψη? Επιτρέψτε μου να ρωτήσω τον παλιό μου φίλο Git. Με βοηθά για πολύ καιρό.

Εγώ - "Hey Git; Είμαι σε μεγάλο βάθος και χρειάζομαι τη βοήθειά σας για την επίλυση αυτού του ζητήματος. "

Git - "Γεια σου! Εντάξει, οπότε πρέπει πρώτα να αρχίσουμε από ό, τι είναι στη ζωή. Δημιουργήστε ένα νέο υποκατάστημα που ονομάζεται αναβάθμιση και υποδείξτε αυτό το υποκατάστημα στον ενεργό κώδικα. Μπορείτε να χρησιμοποιήσετε μια σκληρή επαναφορά git για αυτό. "

Εγώ - "Εντάξει, θα το κάνω".

Σε αυτό το σημείο, η κατάσταση μοιάζει με αυτό.

Χρησιμοποιώντας τις λειτουργίες Git

Git - "Πρέπει να ξέρουμε τι άλλαξε μεταξύ ανάπτυξης και αναβάθμισης. Μπορείτε να αναφέρετε τα αρχεία που διαφέρουν μεταξύ της αναβάθμισής σας και της ανάπτυξης; Ελέγξτε αυτά τα αρχεία ξεχωριστά και καταλάβετε ποιες αλλαγές υπήρξαν. "

Εγώ - "Cool. Βλέπω τρία είδη αλλαγών. Υπάρχει μια υπηρεσία S1 την οποία πρέπει να καλέσω με διαφορετικό τρόπο. Υπάρχει μια υπηρεσία S2 την οποία πρέπει να καλέσω χρησιμοποιώντας ένα διαφορετικό τελικό σημείο. Υπάρχει μια υπηρεσία S3 την οποία πρέπει να καλέσω χρησιμοποιώντας διαφορετικές παραμέτρους. Βλέπω επίσης το αρχείο package.json στον κλάδο της αναβάθμισης έχει κάποια από τα πακέτα που έχουν ήδη αναβαθμιστεί. Επομένως, μόνο μερικά πακέτα πρέπει να αλλάξουν. "

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

Git log on ανάπτυξη υποκαταστήματος

Εγώ - "Ναι, έχω συνολικά τέσσερις δεσμεύσεις στον αναπτυσσόμενο κλάδο. Μια δέσμευση αφορούσε την κατασκευή του έργου. Υπάρχει ένα για κάθε μια από τις τρεις κλήσεις υπηρεσίας. "

Git - "Τέλεια! Φαίνεται ότι ακολουθήσατε σωστά τις βέλτιστες πρακτικές. Ας αρχίσουμε με τη σταθεροποίηση της κατασκευής του έργου κάνοντας το package.json up-to-ημερομηνία. Πραγματοποιήστε την ολοκλήρωση του ελέγχου στον κλάδο της αναβάθμισης και κάντε διπλότυπο του package.json - package-copy.json. Τώρα, χρησιμοποιώντας το Git αντικαταστήστε, αναβαθμίστε / package.json με το develop / package.json και εκτελέστε τη διαφορά μεταξύ του πακέτου package.json και του πακέτου copy.json. Επειδή ο ζωντανός κώδικας έχει ήδη αλλάξει κάποια πακέτα και έχει διαφορετικές εκδόσεις, θα πρέπει να αναβαθμίσετε εξετάζοντας τη διαφορά. "

Δημιουργία του έργου

Εγώ - "Επιτρέψτε μου να το δοκιμάσω. Εντάξει, χτίζει και λειτουργεί. "

Git - "Awesome! Τώρα, ας εργαστούμε στις κλήσεις υπηρεσίας. Βλέπω ότι έχετε μία δέσμευση για κάθε αλλαγή υπηρεσίας-κλήσης στον κλάδο ανάπτυξης. Ώρα να πάρει κεράσι. Επιλέξτε από την λιγότερο περίπλοκη κλήση υπηρεσίας στην πιο περίπλοκη κλήση υπηρεσίας. Επιλογή, συγχώνευση και επίλυση συγκρούσεων. Βεβαιωθείτε ότι έχετε ελέγξει εάν το έργο βρίσκεται σε κατάσταση κατασκευής μετά από κάθε επιλογή κερασιών και πριν από κάθε δέσμευση. "

Εγώ - "S1 γίνει. Το S2 έγινε. Το S3 έγινε. Ευχαριστώ, Git "

Git - "Είστε ευπρόσδεκτοι. Αλλά είστε εσείς που βοήθησε τον εαυτό σας, ακολουθώντας τις πρακτικές του Git και δεν αντιμετωπίζατε το Git ως απλή αποθήκευση κώδικα ».

Τι έκανα εδώ;

Αλλαγές σχετικές με δεσμεύσεις

Πάρτε μια στιγμή για μια στιγμή και σκεφτείτε εάν αυτή η αλλαγή θα πρέπει να πάει σε αυτό το commit. Μια δέσμευση που λέει ότι "αλλαγή: υπηρεσία-s1 τελικά σημεία" και έχει αλλαγές service2 θα δημιουργούσε απλώς σύγχυση.

Μην δεσμεύσετε τη μισή εργασία

Συχνά ακούσαμε το μάντρα "να δεσμεύεται νωρίς, να διαπράττεται συχνά". Στο παραπάνω παράδειγμα, μπορείτε να έχετε μία δέσμευση για διαφορετικά σημεία της ίδιας υπηρεσίας. Αυτό ονομάζεται Making Sausage.

Ωστόσο, προσωπικά squash μικρές δεσμεύσεις μου χρησιμοποιώντας τη διαδραστική λειτουργία git rebase. Αυτό με βοηθά να έχω μια λογική αλλαγή, η οποία μπορεί να πιστοποιηθεί, και βοηθά ένα Trusted Committer να αναθεωρήσει τον κώδικα σας επίσης. Αυτό είναι πολύ προτιμότερο για έργα μεγάλης κλίμακας.

Δοκιμάστε τον κώδικα σας προτού δεσμευθείτε

Πρέπει να σκεφτόμαστε το Git ως κρατικό μηχάνημα και κάθε μηχάνημα πρέπει να είναι σε οικοδομήσιμη κατάσταση σε οποιαδήποτε κατάσταση.

Γράψτε τα μηνύματα Good Commit

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

συμπέρασμα

Ήμουν σε θέση να επιλύσω γρήγορα το χάος. Θα μπορούσα να βγούμε από αυτή τη στιγμή των WTF και FML μόνο επειδή παρακολούθησα κάποιες καλές πρακτικές. Υπάρχουν για ένα λόγο και είναι σαν αλάτι στα τρόφιμα - συνειδητοποιείτε μόνο την αξία τους όταν δεν χρησιμοποιούνται.

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

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

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

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

βιβλιογραφικές αναφορές

  • Git Best Practices
  • Έξυπνη ενσωμάτωση ελέγχου έκδοσης σε VSCode
  • Git Semantic Commit Μηνύματα
  • Git Tip : Πώς να "συγχωνεύσετε" συγκεκριμένα αρχεία από άλλο κλάδο
  • Συμβουλή Git : Τεκμηρίωση Git-git-cherry-pick
  • Git Tip : Git-git-reset Τεκμηρίωση

Ευχαριστώ ιδιαιτέρως τους φίλους μου Saurabh Rajani και Anish Dhargalkar που με βοήθησαν με την περιποίηση του περιεχομένου.