Έχετε μάθει εντολές Git αλλά θέλετε να φανταστείτε πώς λειτουργεί η συνεχής ενοποίηση (CI) στην πραγματικότητα; Ή μήπως θέλετε να βελτιστοποιήσετε τις καθημερινές σας δραστηριότητες; Αυτό το μάθημα θα σας δώσει πρακτικές δεξιότητες στη συνεχή ενσωμάτωση χρησιμοποιώντας ένα αποθετήριο GitHub. Αυτό το μάθημα δεν προορίζεται να είναι ένας μάγος στον οποίο μπορείτε απλά να κάνετε κλικ· αντίθετα, θα εκτελέσετε τις ίδιες ενέργειες που κάνουν οι άνθρωποι στην εργασία, με τον ίδιο τρόπο που το κάνουν. Θα εξηγήσω τη θεωρία καθώς περνάτε από τα σχετικά βήματα.

Τι κάνουμε?

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

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

Θα περάσετε από τα ακόλουθα τυπικά σενάρια CI:

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

Τι θα μάθετε;

Θα είστε σε θέση να απαντήσετε στις ακόλουθες ερωτήσεις:

• Τι είναι η συνεχής ολοκλήρωση (CI);
• Ποιοι τύποι αυτοματοποιημένων δοκιμών χρησιμοποιούνται στο CI και ως απάντηση σε ποιες ενέργειες ενεργοποιούνται;
• Τι είναι τα αιτήματα έλξης και πότε χρειάζονται;
• Τι είναι το Test Driven Development (TDD) και πώς σχετίζεται με το CI;
• Πρέπει να συγχωνεύσω ή να επαναφέρω τις αλλαγές;
• Επαναφορά ή επιδιόρθωση στην επόμενη έκδοση;

Στην αρχή μετέφραζα παντού πράγματα όπως «αιτήματα έλξης», αλλά ως αποτέλεσμα αποφάσισα να επιστρέψω φράσεις στα αγγλικά σε ορισμένα σημεία για να μειώσω τον βαθμό τρέλας στο κείμενο. Μερικές φορές θα χρησιμοποιήσω το "programmer surzhik" όπως το υπέροχο ρήμα "commit" όπου οι άνθρωποι το χρησιμοποιούν πραγματικά στη δουλειά.

Τι είναι η συνεχής ολοκλήρωση;

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

Υπάρχουν διαφωνίες σχετικά με αυτόν τον όρο

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

Μια άλλη αντίρρηση είναι ότι η C++ δεν είναι πλέον η μόνη γλώσσα που χρησιμοποιείται στην ανάπτυξη και η απλή απαίτηση συναρμολόγησης χωρίς σφάλματα ως τρόπος επικύρωσης είναι αδύναμη. Ορισμένα σετ δοκιμών (για παράδειγμα, δοκιμές μονάδας που εκτελούνται τοπικά) πρέπει επίσης να ολοκληρωθούν με επιτυχία. Προς το παρόν, η κοινότητα οδεύει προς το να καταστήσει αυτό μια απαίτηση και στο μέλλον οι "δοκιμές κατασκευής + μονάδας" πιθανότατα θα γίνουν κοινή πρακτική, αν δεν το έχει ήδη κάνει.

Συνεχής ενσωμάτωση διαφορετικό από συνεχής παράδοση (Συνεχής Παράδοση, CD) δεδομένου ότι δεν απαιτεί υποψήφια έκδοση μετά από κάθε κύκλο ολοκλήρωσης.

Λίστα βημάτων που θα χρησιμοποιήσουμε σε όλη τη διάρκεια του μαθήματος

1. Τραβήξτε τον πιο πρόσφατο κωδικό. Δημιουργία υποκαταστήματος από master. Αρχισε να δουλεύεις, άρχισε τη δουλειά.
2. Δημιουργήστε δεσμεύσεις στο νέο σας υποκατάστημα. Κατασκευάστε και δοκιμάστε τοπικά. Πέρασμα? Μεταβείτε στο επόμενο βήμα. Αποτυγχάνω? Διορθώστε σφάλματα ή δοκιμές και δοκιμάστε ξανά.
3. Σπρώξτε στο απομακρυσμένο αποθετήριο ή στον απομακρυσμένο κλάδο σας.
4. Δημιουργήστε ένα αίτημα έλξης. Συζητήστε τις αλλαγές, προσθέστε περισσότερα commit καθώς συνεχίζεται η συζήτηση. Κάντε τις δοκιμές να περάσουν στον κλάδο χαρακτηριστικών.
5. Συγχώνευση/rebase δεσμεύσεις από τον κύριο. Κάντε τις δοκιμές να περάσουν το αποτέλεσμα της συγχώνευσης.
6. Ανάπτυξη από τον κλάδο χαρακτηριστικών στην παραγωγή.
7. Εάν όλα είναι καλά στην παραγωγή για κάποιο χρονικό διάστημα, συγχωνεύστε τις αλλαγές σε κύρια.

️ Προετοιμασία

Βεβαιωθείτε ότι έχετε το σωστό λογισμικό

Για να παρακολουθήσετε αυτό το μάθημα θα χρειαστείτε Node.js и Git client.

Μπορείτε να χρησιμοποιήσετε οποιοδήποτε πρόγραμμα-πελάτη Git, αλλά θα παρέχω εντολές μόνο για τη γραμμή εντολών.

Βεβαιωθείτε ότι έχετε εγκαταστήσει ένα πρόγραμμα-πελάτη Git που υποστηρίζει τη γραμμή εντολών

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

Ετοιμάστε το αποθετήριο

Θα χρειαστεί να δημιουργήσετε ένα προσωπικό αντίγραφο (πηρούνι) αποθετήριο προτύπων με κώδικα για το μάθημα στο GitHub. Ας συμφωνήσουμε να καλέσουμε αυτό το προσωπικό αντίγραφο αποθετήριο μαθημάτων.

Εγινε? Εάν δεν έχετε αλλάξει τις προεπιλεγμένες ρυθμίσεις, πιθανότατα θα καλείται το αποθετήριο μαθημάτων σας continuous-integration-team-scenarios-students, βρίσκεται στον λογαριασμό σας στο GitHub και η διεύθυνση URL μοιάζει με αυτό

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

Θα καλέσω απλώς αυτή τη διεύθυνση <URL репозитория>.

Γωνιακές αγκύλες όπως <тут> θα σημαίνει ότι πρέπει να αντικαταστήσετε μια τέτοια έκφραση με την κατάλληλη τιμή.

Σιγουρέψου ότι Ενέργειες GitHub περιλαμβάνονται για αυτό το αποθετήριο μαθημάτων. Εάν δεν είναι ενεργοποιημένα, ενεργοποιήστε τα κάνοντας κλικ στο μεγάλο κουμπί στη μέση της σελίδας, στο οποίο μπορείτε να μεταβείτε κάνοντας κλικ στο Actions στη διεπαφή GitHub.

Δεν θα μπορείτε να ολοκληρώσετε το μάθημα ακολουθώντας τις οδηγίες μου εάν δεν είναι ενεργοποιημένες οι Ενέργειες GitHub.

Μπορείτε πάντα να χρησιμοποιήσετε την ικανότητα του GitHub να αποδίδει το Markdown για να δείτε την τρέχουσα κατάσταση της λίστας που συνθέτουμε εδώ

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

Σχετικά με τις απαντήσεις

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

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

Χρησιμοποιήστε αυτό μόνο εάν το χρειάζεστε πραγματικά

Δεσμεύστε τον κωδικό σας

git add .
git commit -m "Backing up my work"

Αυτές οι εντολές

• μετονομάζω master в master-backup;
• μετονομάζω solution в master;
• ταμείο σε νέο υποκατάστημα master και ξαναγράψτε τα περιεχόμενα του καταλόγου εργασίας.
• Δημιουργήστε έναν κλάδο "λύσης" από τον "κύριο" (που παλαιότερα ήταν "λύση") σε περίπτωση που χρειαστείτε έναν κλάδο "λύσης" στο μέλλον.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Μετά από αυτά τα βήματα μπορείτε να χρησιμοποιήσετε git log master για να καταλάβετε ποια δέσμευση χρειάζεστε.
Μπορείτε να επαναφέρετε τον κατάλογο εργασίας σας σε αυτό το commit ως εξής:

git reset --hard <the SHA you need>

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

git push --force origin master

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

Ξεκινώντας τη δουλειά

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

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

1. Κλωνοποιήστε το αποθετήριο μαθημάτων από <URL репозитория>.
2. Τρέξιμο npm install στον κατάλογο αποθετηρίου μαθημάτων. Το χρειαζόμαστε για να εγκαταστήσουμε το Jest, το οποίο χρησιμοποιούμε για την εκτέλεση δοκιμών.
3. Δημιουργήστε ένα υποκατάστημα και ονομάστε το feature. Μετάβαση σε αυτό το νήμα.

4. Προσθήκη κωδικού δοκιμής σε ci.test.js ανάμεσα στα σχόλια που μου ζητούν να το κάνω αυτό.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Προσθέστε κείμενο με τα πρώτα 4 βήματα στο αρχείο ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   Ομάδες

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Δημιουργήστε δεσμεύσεις σε ένα νέο κλάδο, δημιουργήστε και δοκιμάστε τοπικά

Θα ρυθμίσουμε τις δοκιμές για εκτέλεση πριν από τη δέσμευση και, στη συνέχεια, θα δεσμεύσουμε τον κώδικα.

Τυπικά σενάρια όταν οι δοκιμές εκτελούνται αυτόματα

• Τοπικά:
  • Συνεχώς ή ως απόκριση σε κατάλληλες αλλαγές κώδικα.
  • Σχετικά με την αποθήκευση (για διερμηνευμένες ή μεταγλωττισμένες γλώσσες JIT).
  • Κατά τη συναρμολόγηση (όταν απαιτείται μεταγλώττιση).
  • Σε δέσμευση?
  • Κατά τη δημοσίευση σε κοινόχρηστο αποθετήριο.

• Στον διακομιστή κατασκευής ή στο περιβάλλον κατασκευής:
  • Όταν ο κώδικας δημοσιεύεται σε προσωπικό υποκατάστημα/αποθήκη.
  • Ο κώδικας σε αυτό το νήμα δοκιμάζεται.
  • Το πιθανό αποτέλεσμα της συγχώνευσης ελέγχεται (συνήθως με master).
  • Ως αγωγός συνεχούς ολοκλήρωσης/συνεχούς παράδοσης

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

• Γρήγορες δοκιμές μονάδας - κατά την κατασκευή, σε αγωγό CI
• Αργές δοκιμές μονάδων, γρήγορες δοκιμές εξαρτημάτων και ολοκλήρωσης - κατά τη δέσμευση, στον αγωγό CI
• Αργές δοκιμές εξαρτημάτων και ολοκλήρωσης - στον αγωγό CI
• Δοκιμές ασφαλείας, δοκιμές φορτίου και άλλες χρονοβόρες ή δαπανηρές δοκιμές - σε αγωγούς CI/CD, αλλά μόνο σε ορισμένες λειτουργίες/στάδια/σωλήνες της κατασκευής, για παράδειγμα, κατά την προετοιμασία μιας υποψήφιας έκδοσης ή όταν εκτελείται χειροκίνητα.

️Εργασία

Προτείνω να εκτελέσετε τις δοκιμές χειροκίνητα πρώτα χρησιμοποιώντας την εντολή npm test. Μετά από αυτό, ας προσθέσουμε ένα git hook για να εκτελέσουμε τις δοκιμές μας κατά την δέσμευση. Υπάρχει ένα πρόβλημα: Τα άγκιστρα Git δεν θεωρούνται μέρος του αποθετηρίου και επομένως δεν μπορούν να κλωνοποιηθούν από το GitHub μαζί με το υπόλοιπο υλικό μαθημάτων. Για να εγκαταστήσετε το άγκιστρο πρέπει να τρέξετε install_hook.sh ή αντιγράψτε το αρχείο repo/hooks/pre-commit στον τοπικό κατάλογο .git/hooks/.
Όταν κάνετε δέσμευση, θα δείτε ότι εκτελούνται δοκιμές και ελέγχουν εάν υπάρχουν ορισμένες λέξεις-κλειδιά στη λίστα.

1. Εκτελέστε τις δοκιμές χειροκίνητα εκτελώντας την εντολή npm test στον φάκελο αποθετηρίου μαθημάτων σας. Βεβαιωθείτε ότι οι δοκιμές έχουν ολοκληρωθεί.
2. Ορίστε ένα άγκιστρο δέσμευσης (pre-commit hook) τρέχοντας install_hook.sh.
3. Δεσμεύστε τις αλλαγές σας στο τοπικό σας αποθετήριο.
4. Βεβαιωθείτε ότι έχουν εκτελεστεί δοκιμές πριν από τη δέσμευση.

Το αποθετήριο σας θα πρέπει να μοιάζει με αυτό αφού ακολουθήσετε αυτά τα βήματα.

Ομάδες

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Δημοσίευση κώδικα σε απομακρυσμένο χώρο αποθήκευσης ή απομακρυσμένο υποκατάστημα

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

• Με τα forks, ένας προγραμματιστής κλωνοποιεί ένα απομακρυσμένο κοινόχρηστο αποθετήριο, δημιουργώντας ένα προσωπικό απομακρυσμένο αντίγραφό του, γνωστό και ως fork. Στη συνέχεια, κλωνοποιεί αυτό το προσωπικό αποθετήριο για να συνεργαστεί τοπικά. Όταν ολοκληρωθεί η εργασία και πραγματοποιηθούν οι δεσμεύσεις, τα σπρώχνει στο πιρούνι του, όπου είναι διαθέσιμα σε άλλους και μπορούν να ενσωματωθούν στο κοινό αποθετήριο. Αυτή η προσέγγιση χρησιμοποιείται συνήθως σε έργα ανοιχτού κώδικα στο GitHub. Χρησιμοποιείται επίσης στο προχωρημένο μάθημά μου [Ομαδική εργασία και CI με το Git] (http://devops.redpill.solutions/).
• Μια άλλη προσέγγιση είναι να χρησιμοποιήσετε μόνο ένα απομακρυσμένο αποθετήριο και να μετρήσετε μόνο τον κλάδο master κοινόχρηστο αποθετήριο "προστατεύεται". Σε αυτό το σενάριο, μεμονωμένοι προγραμματιστές δημοσιεύουν τον κώδικά τους σε υποκαταστήματα ενός απομακρυσμένου αποθετηρίου, έτσι ώστε άλλοι να μπορούν να δουν αυτόν τον κώδικα, εάν όλα είναι εντάξει, να τον συγχωνεύσουν με master κοινόχρηστο αποθετήριο.

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

Ας δημοσιεύσουμε τον κωδικό μας.

️Εργασία

• Δημοσιεύστε τις αλλαγές σε έναν απομακρυσμένο κλάδο με το ίδιο όνομα με τον κλάδο εργασίας σας

Ομάδες

git push --set-upstream origin feature

Δημιουργήστε ένα αίτημα έλξης

Δημιουργήστε ένα αίτημα έλξης με τίτλο Αναθεώρηση βημάτων... Εγκαθιστώ feature όπως «κεφάλι κλαδί» και master σαν «κλαδί βάσης».

Βεβαιωθείτε ότι έχετε εγκαταστήσει master στο δικό του πιρούνι το αποθετήριο Ως "βασικός κλάδος", δεν θα απαντήσω σε αιτήματα για αλλαγές στο αποθετήριο υλικών μαθημάτων.

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

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

Αίτημα έλξης (PR)

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

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

• Οργάνωση συζητήσεων σχετικά με συγκεκριμένες αλλαγές κώδικα.
• ως ένα μέρος για την προβολή σχολίων σχετικά με τις εργασίες σε εξέλιξη τόσο από αυτοδοκιμαστές όσο και από ομοτίμους.
• επισημοποίηση των αναθεωρήσεων κώδικα·
• έτσι ώστε αργότερα να μπορείτε να μάθετε τους λόγους και τις σκέψεις πίσω από αυτό ή εκείνο το κομμάτι κώδικα.

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

Συνήθως, όταν δημιουργείτε ένα PR, κάνετε τα εξής.

• Υποδείξτε τι προτείνετε να αλλάξετε και πού.
• Γράψτε μια περιγραφή εξηγώντας το σκοπό των αλλαγών. Μπορεί να θέλετε:
  • προσθέστε οτιδήποτε σημαντικό που δεν είναι προφανές από τον κώδικα ή κάτι χρήσιμο για την κατανόηση του περιβάλλοντος, όπως σχετικά #bugs και αριθμούς δέσμευσης.
  • @αναφέρετε οποιονδήποτε θέλετε να αρχίσετε να συνεργάζεστε ή μπορείτε να τον @αναφέρετε στα σχόλια αργότερα.
  • ζητήστε από τους συναδέλφους να σας βοηθήσουν σε κάτι ή ελέγξτε κάτι συγκεκριμένο.

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

Περιμένετε μέχρι να ολοκληρωθούν οι δοκιμές. Μπορείτε να δείτε την κατάσταση των δοκιμών στο κάτω μέρος της συζήτησης PR στη διεπαφή GitHub. Συνεχίστε όταν ολοκληρωθούν οι δοκιμές.

️ Προσθέστε μια σημείωση σχετικά με την τυχαιότητα της λίστας βημάτων CI

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

️ Εργασία: δημιουργήστε ένα αίτημα έλξης για αυτό το σχόλιο

1. Μετάβαση σε υποκατάστημα master.
2. Δημιουργήστε ένα υποκατάστημα με όνομα bugfix.
3. Προσθέστε κείμενο σημείωσης στο τέλος του αρχείου ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. Δεσμεύστε τις αλλαγές.
5. Δημοσιεύστε το νήμα bugfix σε ένα απομακρυσμένο αποθετήριο.
6. Δημιουργήστε ένα αίτημα έλξης με όνομα Προσθήκη παρατήρησης με ένα κλαδί κεφαλής bugfix και τον κλάδο βάσηςmaster.

Βεβαιωθείτε ότι έχετε εγκαταστήσει master στο δικό του πιρούνι το αποθετήριο Ως "βασικός κλάδος", δεν θα απαντήσω σε αιτήματα για αλλαγές στο αποθετήριο υλικών μαθημάτων.

Έτσι πρέπει να μοιάζει το αποθετήριο σας.

Ομάδες

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Έγκριση αιτήματος έλξης "Προσθήκη παρατήρησης"

️Εργασία

1. Δημιουργήστε ένα αίτημα έλξης.
2. Κάντε κλικ στο "Αίτημα έλξης συγχώνευσης".
3. Κάντε κλικ στο "Επιβεβαίωση συγχώνευσης".
4. Κάντε κλικ στο "Διαγραφή υποκαταστήματος", δεν το χρειαζόμαστε πλέον.

Αυτό είναι ένα διάγραμμα δεσμεύσεων μετά από συγχώνευση.

️ Συνεχίστε να εργάζεστε και να προσθέτετε δοκιμές

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

Η συνεχής ολοκλήρωση συνήθως περιλαμβάνει κάποια δοκιμαστική κάλυψη. Οι απαιτήσεις κάλυψης των δοκιμών ποικίλλουν και συνήθως βρίσκονται σε ένα έγγραφο που ονομάζεται κάτι σαν "οδηγίες συνεισφοράς". Θα το κρατήσουμε απλό και θα προσθέσουμε μια δοκιμή για κάθε γραμμή στη λίστα ελέγχου μας.

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

Δοκιμαστική Ανάπτυξη (TDD)

Το TDD συνιστά τη σύνταξη δοκιμών πριν από τον κώδικα. Μια τυπική ροή εργασίας που χρησιμοποιεί το TDD μοιάζει με αυτό.

1. Προσθέστε ένα τεστ.
2. Εκτελέστε όλες τις δοκιμές και βεβαιωθείτε ότι η νέα δοκιμή αποτυγχάνει.
3. Γράψε τον κωδικό.
4. Εκτελέστε τα τεστ, βεβαιωθείτε ότι όλα τα τεστ περάσουν.
5. Αναδιαμορφώστε τον κωδικό σας.
6. Επαναλαμβάνω.

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

️Εργασία

Πρώτα, δοκιμάστε να πραγματοποιήσετε τις δοκιμές και να τις αφήσετε να αποτύχουν και, στη συνέχεια, προσθέστε και δεσμεύστε το κείμενο της ίδιας της λίστας βημάτων CI. Θα δείτε ότι τα τεστ περνούν («πράσινα»).
Στη συνέχεια, δημοσιεύστε τον νέο κώδικα στο απομακρυσμένο αποθετήριο και παρακολουθήστε τις δοκιμές που εκτελούνται στη διεπαφή GitHub στο κάτω μέρος της συζήτησης του αιτήματος έλξης και της ενημέρωσης κατάστασης PR.

1. Μετάβαση σε υποκατάστημα feature.

2. Προσθέστε αυτές τις δοκιμές σε ci.test.js μετά την τελευταία κλήση it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Προσπαθήστε να κάνετε τις δοκιμές. Αν pre-commit Το άγκιστρο έχει εγκατασταθεί, η προσπάθεια δέσμευσης θα αποτύχει.
4. Στη συνέχεια, προσθέστε αυτό το κείμενο στο ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. Κάντε και πραγματοποιήστε αλλαγές τοπικά.
6. Δημοσιεύστε αλλαγές στο υποκατάστημα feature.

Θα πρέπει τώρα να έχετε κάτι τέτοιο

Ομάδες

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Συγχώνευση σύγκρουσης

Μεταβείτε στο Αίτημα αλλαγής Αναθεώρηση βημάτων.

Παρόλο που δεν κάναμε τίποτα λάθος και οι δοκιμές για τον κωδικό μας πέρασαν, δεν μπορούμε να συγχωνεύσουμε τον κλάδο feature и master. Είναι επειδή το άλλο νήμα bugfix συγχωνεύτηκε με master ενώ εργαζόμασταν σε αυτό το PR.
Αυτό δημιουργεί μια κατάσταση όπου ο απομακρυσμένος κλάδος master έχει νεότερη έκδοση από αυτή στην οποία βασίσαμε το υποκατάστημα feature. Εξαιτίας αυτού δεν μπορούμε απλώς να γυρίσουμε το ΚΕΦΑΛΙ προς τα πίσω master μέχρι το τέλος του νήματος feature. Σε αυτήν την περίπτωση, πρέπει είτε να συγχωνεύσουμε είτε να εφαρμόσουμε δεσμεύσεις feature αναβάση master. Το GitHub μπορεί πραγματικά να πραγματοποιήσει αυτόματες συγχωνεύσεις εάν δεν υπάρχουν διενέξεις. Δυστυχώς, στην περίπτωσή μας, και οι δύο κλάδοι έχουν ανταγωνιστικές αλλαγές στο αρχείο ci.md. Αυτή η κατάσταση είναι γνωστή ως διένεξη συγχώνευσης και πρέπει να την επιλύσουμε με μη αυτόματο τρόπο.

Συγχώνευση ή επαναφορά

πηγαίνω

• Δημιουργεί μια πρόσθετη δέσμευση συγχώνευσης και αποθηκεύει το ιστορικό εργασίας.
  • Διατηρεί τις αρχικές δεσμεύσεις των υποκαταστημάτων με τις αρχικές χρονικές σημάνσεις και τους συγγραφείς τους.
  • Αποθηκεύει το SHA των δεσμεύσεων και τους συνδέσμους σε συζητήσεις αιτημάτων αλλαγής.
• Απαιτεί εφάπαξ επίλυση συγκρούσεων.
• Κάνει την ιστορία μη γραμμική.
  • Η ιστορία μπορεί να είναι δύσκολο να διαβαστεί λόγω του μεγάλου αριθμού διακλαδώσεων (θυμίζει καλώδιο IDE).
  • Κάνει πιο δύσκολο τον αυτόματο εντοπισμό σφαλμάτων, π.χ. git bisect λιγότερο χρήσιμο - θα βρει μόνο τη δέσμευση συγχώνευσης.

Επανάληψη

• Οι επαναλήψεις δεσμεύονται από τον τρέχοντα κλάδο πάνω από τον κλάδο βάσης το ένα μετά το άλλο.
  • Δημιουργούνται νέες δεσμεύσεις με νέα SHA, με αποτέλεσμα οι δεσμεύσεις στο GitHub να ταιριάζουν με τα αρχικά αιτήματα έλξης, αλλά όχι με τα αντίστοιχα σχόλια.
  • Οι δεσμεύσεις μπορούν να ανασυνδυαστούν και να τροποποιηθούν στη διαδικασία, ή ακόμα και να συγχωνευθούν σε μία.
• Μπορεί να χρειαστεί να επιλυθούν πολλές συγκρούσεις.
• Σας επιτρέπει να διατηρείτε μια γραμμική ιστορία.
  • Η ιστορία μπορεί να είναι πιο εύκολη στην ανάγνωση, αρκεί να μην είναι πολύ μεγάλη χωρίς εύλογο λόγο.
  • Ο αυτόματος εντοπισμός σφαλμάτων και η αντιμετώπιση προβλημάτων είναι λίγο πιο εύκολος: το καθιστά δυνατό git bisect, μπορεί να κάνει τις αυτόματες επαναλήψεις πιο σαφείς και πιο προβλέψιμες.
• Απαιτεί τη δημοσίευση ενός κλάδου με μετεγκατάσταση δεσμεύσεων με σημαία --force όταν χρησιμοποιείται με αιτήματα έλξης.

Συνήθως, οι ομάδες συμφωνούν να χρησιμοποιούν πάντα την ίδια στρατηγική όταν χρειάζεται να συγχωνεύσουν αλλαγές. Αυτό θα μπορούσε να είναι μια "καθαρή" συγχώνευση ή μια "καθαρή" δέσμευση στην κορυφή, ή κάτι ενδιάμεσο, όπως να κάνετε μια δέσμευση στην κορυφή διαδραστικά (git rebase -i) τοπικά για υποκαταστήματα που δεν δημοσιεύονται στο δημόσιο αποθετήριο, αλλά συγχωνεύονται για "δημόσια" υποκαταστήματα.

Εδώ θα χρησιμοποιήσουμε τη συγχώνευση.

️Εργασία

1. Βεβαιωθείτε ότι ο κωδικός βρίσκεται σε τοπικό υποκατάστημα master ενημερώθηκε από ένα απομακρυσμένο αποθετήριο.
2. Μετάβαση σε υποκατάστημα feature.
3. Ξεκινήστε μια συγχώνευση με έναν κλάδο master. Διένεξη συγχώνευσης λόγω ανταγωνιστικών αλλαγών στο ci.md.
4. Επιλύστε τη διένεξη, ώστε να παραμείνουν στο κείμενο τόσο η λίστα με τα βήματα CI όσο και μια σημείωση σχετικά με αυτήν.
5. Δημοσιεύστε μια δέσμευση συγχώνευσης σε έναν απομακρυσμένο κλάδο feature.
6. Ελέγξτε την κατάσταση του αιτήματος έλξης στο GitHub UI και περιμένετε μέχρι να επιλυθεί η συγχώνευση.

Ομάδες

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Καλή δουλειά!

Τελειώσατε με τη λίστα και τώρα πρέπει να εγκρίνετε το αίτημα έλξης master.

️ Εργασία: Έγκριση αιτήματος έλξης "Έλεγχος βημάτων"

1. Ανοίξτε ένα αίτημα έλξης.
2. Κάντε κλικ στο "Αίτημα έλξης συγχώνευσης".
3. Κάντε κλικ στο "Επιβεβαίωση συγχώνευσης".
4. Κάντε κλικ στο «Διαγραφή υποκαταστήματος» γιατί δεν το χρειαζόμαστε πλέον.

Αυτό είναι το αποθετήριό σας αυτή τη στιγμή

Σφάλμα προϊόντος

Λέγεται ότι «η δοκιμή μπορεί να χρησιμοποιηθεί για να δείξει την παρουσία σφαλμάτων, αλλά ποτέ για να δείξει την απουσία τους». Παρόλο που κάναμε δοκιμές και δεν μας έδειξαν σφάλματα, ένα ύπουλο σφάλμα εισήλθε στην παραγωγή.

Σε ένα τέτοιο σενάριο, πρέπει να προσέξουμε:

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

Πρέπει να κάνω επαναφορά ή να το διορθώσω στην επόμενη έκδοση;

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

Δεδομένου ότι η ανατροπή δεν εγκυμονεί κανέναν κίνδυνο στην περίπτωσή μας, θα ακολουθήσουμε αυτή τη διαδρομή, γιατί μας επιτρέπει

• διορθώστε το σφάλμα στο προϊόν το συντομότερο δυνατό.
• δημιουργήστε κωδικό master αμέσως κατάλληλο για έναρξη νέας εργασίας.

️Εργασία

1. Μετάβαση σε υποκατάστημα master τοπικά.
2. Ενημερώστε το τοπικό αποθετήριο από το απομακρυσμένο αποθετήριο.
3. Επαναφέρετε τη δέσμευση συγχώνευσης PR Αναθεώρηση βημάτων в master.
4. Δημοσίευση αλλαγών σε απομακρυσμένο χώρο αποθήκευσης.

Αυτό είναι το ιστορικό ενός αποθετηρίου με επαναφορά μιας δέσμευσης συγχώνευσης

Ομάδες

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Αυτοέλεγχος

Σιγουρέψου ότι ci.md δεν περιέχει πλέον το κείμενο "ύπουλο σφάλμα" μετά την επαναφορά μιας δέσμευσης συγχώνευσης.

Διορθώστε τη λίστα των βημάτων CI και επιστρέψτε την στην κύρια

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

Μπορούμε να προσεγγίσουμε το πρόβλημα με διάφορους τρόπους:

• επαναφέρετε μια δέσμευση που αναιρεί μια συγχώνευση feature с master;
• κίνηση δεσμεύει από το προηγούμενο feature.

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

️Εργασία

1. Δημιουργήστε ένα νήμα που ονομάζεται feature-fix και μεταβείτε σε αυτό.

2. Μεταφορά όλων των δεσμεύσεων από τον προηγούμενο κλάδο feature σε ένα νέο νήμα. Επίλυση διενέξεων συγχώνευσης που προέκυψαν κατά τη μετεγκατάσταση.

   

3. Προσθέστε ένα τεστ παλινδρόμησης στο ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Εκτελέστε τα τεστ τοπικά για να βεβαιωθείτε ότι δεν θα αποτύχουν.
5. Καταργήστε το κείμενο "with a sneaky bug". ci.md.
6. Προσθέστε αλλαγές δοκιμής και αλλαγές στη λίστα βημάτων στο ευρετήριο και δεσμεύστε τις.
7. Δημοσιεύστε το υποκατάστημα σε ένα απομακρυσμένο αποθετήριο.

Θα πρέπει να καταλήξετε με κάτι παρόμοιο με αυτό:

Ομάδες

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Δημιουργήστε ένα αίτημα έλξης.

Δημιουργήστε ένα αίτημα έλξης με τίτλο Διόρθωση της δυνατότητας... Εγκαθιστώ feature-fix όπως «κεφάλι κλαδί» και master σαν «κλαδί βάσης».
Περιμένετε μέχρι να ολοκληρωθούν οι δοκιμές. Μπορείτε να δείτε την κατάσταση των δοκιμών στο κάτω μέρος της συζήτησης PR.

Βεβαιωθείτε ότι έχετε εγκαταστήσει master στο δικό του πιρούνι το αποθετήριο Ως "βασικός κλάδος", δεν θα απαντήσω σε αιτήματα για αλλαγές στο αποθετήριο υλικών μαθημάτων.

Έγκριση αιτήματος έλξης "Διόρθωση της δυνατότητας"

Ευχαριστώ για τη διόρθωση! Εγκρίνετε τις αλλαγές σε master από αίτημα έλξης.

️Εργασία

1. Κάντε κλικ στο "Αίτημα έλξης συγχώνευσης".
2. Κάντε κλικ στο "Επιβεβαίωση συγχώνευσης".
3. Κάντε κλικ στο «Διαγραφή υποκαταστήματος» γιατί δεν το χρειαζόμαστε πλέον.

Αυτό πρέπει να έχετε αυτή τη στιγμή.

Συγχαρητήρια!

Έχετε ολοκληρώσει όλα τα βήματα που κάνουν συνήθως οι άνθρωποι κατά τη συνεχή ενσωμάτωση.

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

Πηγή: www.habr.com