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

Αρχικοποίηση αποθετηρίου

Αφού αρχικοποιήσετε το αποθετήριο, δημιουργήστε ένα ανάπτυξη και master κλάδος αν δεν είχε συμπεριληφθεί από προεπιλογή. Ο κλάδος develop θα πρέπει να περιέχει ένα development κωδικός που είναι ένας καθρέφτης του κύριου κλάδου με νέα χαρακτηριστικά. Ο κύριος κλάδος περιέχει μια σταθερή έκδοση του κώδικα, που αντιπροσωπεύει την κατάσταση παραγωγής. Και τα δύο έχουν άπειρη διάρκεια ζωής και σε σύγκριση με άλλους κλάδους στο Git Flow, δεν θα αφαιρεθούν ποτέ. Ορίστε τους κατάλληλους κανόνες προστασίας: απαιτήστε τις αναθεωρήσεις των αιτημάτων έλξης πριν από τη συγχώνευση και απαιτούν να περάσουν οι έλεγχοι κατάστασης πριν από τη συγχώνευση. Μπορείτε επίσης να εξετάσετε το ενδεχόμενο να επιτρέπετε μόνο επιλεγμένα ομάδα μέλη για να συγχωνεύσουν τις αλλαγές στο master.

$ git init
$ git commit --allow-empty -m "Αρχική δέσμευση"
$ git checkout -b develop master

ΣΗΜΕΙΩΣΗ: Μερικές φορές είναι σημαντικό για το έργο να προστεθούν περισσότεροι άπειροι κλάδοι, για παράδειγμα, για να αντιπροσωπεύουν τα διαθέσιμα περιβάλλοντα. Ωστόσο, διατηρήστε τον "κανόνα των δύο" αν είναι δυνατόν.

Κλάδοι χαρακτηριστικών

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

 $ git checkout develop && git pull --rebase

Στη συνέχεια, μεταβείτε στο feature branch σας. Ονομάστε το αντίστοιχα με το δεδομένο σχήμα: χαρακτηριστικό-JIRA-TASK-ID ή μπορείτε επίσης να παραβείτε αυτόν τον κανόνα και να το ονομάσετε διαφορετικά. Σε αυτή την περίπτωση, βεβαιωθείτε ότι δεν έρχεται σε σύγκρουση με πρότυπα που προορίζονται για την έκδοση, το hotfix, το bugfix, την ανάπτυξη ή τον κύριο κλάδο. Η διατήρηση των αναγνωριστικών εργασιών JIRA θα σας βοηθήσει να διαχειριστείτε αποτελεσματικότερα τους κλάδους χαρακτηριστικών σας.

$ git checkout -b feature-JIRA-TASK-ID develop

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

 $ git add .
 $ git commit -m "JIRA-TASK-ID: Περιγραφή εργασίας"

Συνιστάται να προσθέτετε περισσότερες δεσμεύσεις στον τοπικό σας κλάδο, ακολουθώντας τον κανόνα "Δεσμεύσου νωρίς και συχνά". Ωστόσο, στο τέλος, θα πρέπει να συμπιεστούν σε μια ενιαία δέσμευση που αντιπροσωπεύει ένα JIRA Task. Η συχνή δέσμευση θα σας βοηθήσει να διαχειριστείτε το ιστορικό ανάπτυξης. Όταν το χαρακτηριστικό είναι έτοιμο, ήρθε η ώρα να ανοίξετε ένα Pull Request για την ανάπτυξη ενός κλάδου. Αρχικά, μπορείτε να προωθήσετε τον τοπικό σας κλάδο αν δεν έχει προωθηθεί πολύ μακριά:

 $ git push origin feature-JIRA-TASK-ID

Όταν το υποκατάστημα είναι έτοιμο, ανοίξτε το pull request στο GitHub, ακολουθώντας αυτό το άρθρο: https://help.github.com/en/articles/creating-a-pull-request

Προτού ανοίξετε ένα pull request, βεβαιωθείτε για τα εξής:

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

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # use -i flag for squash
$ git push -f origin feature-JIRA-TASK-ID 1TP65Χρησιμοποιήστε το προσεκτικά καθώς η σημαία -f αντικαθιστά το απομακρυσμένο αποθετήριο

• κρατήστε μόνο σημαντικές δεσμεύσεις - κάθε δέσμευση θα πρέπει να αντιπροσωπεύεται από εργασία JIRA, για παράδειγμα, JIRA-TASK-ID: Διαμόρφωση νέου χαρακτηριστικού, άλλοι πρέπει να είναι συνθλίβονται κατά την επαναπροσδιορισμό τον κλάδο σας με τον κλάδο develop
• έχετε το επιλέγεται ο κατάλληλος κλάδος προορισμού
• δεν ξεχνάτε να να αλλάξετε την κατάσταση της εργασίας σας στο JIRA

Συγχώνευση κλάδου χαρακτηριστικών

Ήρθε η ώρα να συγχωνεύσετε τις αλλαγές σας στον κλάδο ανάπτυξης όταν:

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

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

 $ git checkout develop
 $ git merge feature-JIRA-TASK-ID
 $ git push origin develop
 $ git branch -d feature-JIRA-TASK-ID
 $ git push origin :feature-JIRA-TASK-ID

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

Απελευθερώσεις

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

Σημασιολογική έκδοση

Το να δώσετε σε έναν κλάδο έκδοσης ένα κατάλληλο όνομα και μια αντίστοιχη ετικέτα δεν είναι εύκολη υπόθεση στην αρχή. Είναι καλή πρακτική να αρχίσετε να χρησιμοποιείτε τη σημασιολογική έκδοση (https://semver.org/) που επιτρέπει καλύτερο έλεγχο και κάνει την ανάγνωση του ιστορικού git ευκολότερη. Η συμβολοσειρά έκδοσης κατασκευάζεται σύμφωνα με το σχήμα MAJOR.MINOR.PATCH:

• MAJOR - αλλαγή που αντιπροσωπεύει μη συμβατές αλλαγές API
• MINOR - προσθήκη νέων χαρακτηριστικών με τρόπο συμβατό προς τα πίσω
• PATCH - προσθέτοντας διορθώσεις σφαλμάτων συμβατών προς τα πίσω

Μπορείτε επίσης να χρησιμοποιήσετε ειδικές καταλήξεις, όπως αυτές που αντιπροσωπεύουν κλάδους beta ή legacy, ή να δημιουργήσετε προ-εκδόσεις. Σε αυτή την περίπτωση, ονομάστε την κατάλληλα, π.χ. 1.1.0-beta.4, 1.1.0-beta.5 ή 1.1.0-alpha.

Κάνοντας μια απελευθέρωση

Ο κλάδος release θα πρέπει να είναι παιδί του develop και θα μπορεί να περιέχει μόνο εντολές που σχετίζονται με διορθώσεις σφαλμάτων.

Το όνομα του κλάδου θα πρέπει να βασίζεται στην έκδοση έκδοσης, με το πρόθεμα release-: release-MAJOR.MINOR.PATCH. Ο κλάδος έκδοσης θα πρέπει να είναι πλήρως δοκιμασμένο τόσο αυτόματα όσο και χειροκίνητα στο περιβάλλον σταδιοποίησης. Εάν εμφανιστούν σφάλματα, αυτή είναι η τελευταία ευκαιρία να προωθήσετε τις κατάλληλες διορθώσεις και να εκτελέσετε εκ νέου όλη τη διαδικασία, εφόσον δεν θα είναι θετικά ελεγμένη και έτοιμη για περαιτέρω επεξεργασία. Στη συνέχεια, θα πρέπει να προωθηθεί η δέσμευση της έκδοσης, με αλλαγές της τρέχουσας συμβολοσειράς έκδοσης της έκδοσης σε αρχεία, όπως το package.json. Θα πρέπει επίσης να έχει αντίκτυπο στο αρχείο CHANGELOG.md. Αυτό θα σας βοηθήσει να εντοπίσετε όλες τις αλλαγές πριν από μια σωστή έκδοση και να προετοιμάσετε το περιεχόμενο για την έκδοση στο GitHub όταν ολοκληρωθεί η διαδικασία συγχώνευσης. Η ενημέρωση του ενιαίου αρχείου θα πρέπει να αποτελείται από όλες τις αλλαγές της έκδοσης ομαδοποιημένες σε τρεις κατηγορίες: χαρακτηριστικά, διορθώσεις και συντήρηση.

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

 $ git checkout master && git pull --rebase
 $ git checkout develop && git pull --rebase
 $ git merge master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "Προϊόν Όνομα M.M.P. release"
 $ git push origin release-M.M.P

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

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # Το μήνυμα προσθήκης μπορεί να οριστεί μέσω της σημαίας -m
 $ git push origin M.M.P
 $ git push origin master
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.P

Στη συνέχεια, μεταβείτε στη σελίδα δημοσιεύσεων του GitHub και πατήστε το κουμπί "Draft new release". Στην εμφανιζόμενη φόρμα, επιλέξτε την ετικέτα τρέχουσας έκδοσης, ορίστε τον τίτλο της έκδοσης παρόμοιο με τη δέσμευση της έκδοσης (Product Name M.M.P release) και μια κατάλληλη περιγραφή, με βάση το αρχείο CHANGELOG.md. Για δημόσια έργα, η περιγραφή θα πρέπει να περιέχει έναν κατάλογο όλων των PR που περιλαμβάνονται στην τρέχουσα έκδοση.

Σε περίπτωση που κάποιες διορθώσεις σφαλμάτων εφαρμόστηκαν στον κλάδο έκδοσης, βεβαιωθείτε ότι έχετε ενημερώσει τον κλάδο ανάπτυξης:

$ git checkout develop && git merge master
$ git push origin develo

Hotfixes και διορθώσεις σφαλμάτων

Η κύρια διαφορά μεταξύ ενός σφάλματος και των άμεσων διορθώσεων είναι οι κλάδοι-στόχοι τους.

Διόρθωση σφαλμάτων

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

 $ git checkout release-M.M.P && git pull --rebase
 $ git checkout -b bugfix-M.M.P

Στη συνέχεια, δεσμεύστε τις απαραίτητες αλλαγές. Αφού ολοκληρωθεί η διαδικασία, δημιουργήστε ένα pull request και στοχεύστε το στον κλάδο release. Ακολουθήστε την καθοδήγηση από την ενότητα του κλάδου χαρακτηριστικών. Ο τίτλος της τελικής σας δέσμευσης θα πρέπει να ταιριάζει με το συγκεκριμένο σχήμα: "Bugfix M.M.P: Problem essence fix". Όταν το pull request εγκριθεί, είναι ώρα να το συγχωνεύσετε στην τρέχουσα έκδοση.

 $ git checkout release-M.M.P
 $ git merge bugfix-M.M.P
 $ git push origin release-M.M.P

Hotfix

Για να εκτελέσετε ένα hotfix στο master branch, πρέπει να ακολουθήσετε βήματα παρόμοια με εκείνα ενός bugfix, έχοντας υπόψη ότι ο κλάδος-στόχος είναι πλέον ο master branch.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P αντιπροσωπεύει την τρέχουσα έκδοση

Στη συνέχεια, ακολουθήστε τα συνηθισμένα βήματα ανάπτυξης και όταν η διαδικασία ολοκληρωθεί, δημιουργήστε ένα pull request με στόχο το master branch. Λάβετε υπόψη ότι η τελική δέσμευση θα πρέπει να ταιριάζει με το συγκεκριμένο σχήμα "Hotfix X.Y.(Z + 1): Z.Y.: Problem essence fix". Όταν κάθε σημείο ελέγχου έχει περάσει επιτυχώς, εκτελέστε μια συγχώνευση στο master. Αυτά τα βήματα διαφέρουν από αυτά που παρουσιάζονται για ένα bugfix, καθώς πρέπει να κάνουμε bump στην τρέχουσα έκδοση έκδοσης.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # μήνυμα προσθήκης μπορεί να οριστεί μέσω της σημαίας -m
 $ git push origin X.Y.(Z+1)
 $ git push origin master
 $ git branch -d hotfix-X.Y.(Z+1)
 $ git push origin :hotfix-X.Y.(Z+1)
 $ git checkout develop && git merge master
 $ git push origin develop

Φύλλο εξαπάτησης

Ενεργοποίηση αποθετηρίου

 $ git init
 $ git commit --allow-empty -m "Αρχική δέσμευση"
 $ git checkout -b develop master
 $ git push origin develop
 $ git push origin master

Χαρακτηριστικά

$ git checkout develop && git pull --rebase
$ git checkout -b feature-JIRA-TASK-ID develop

Ξεκινήστε την ανάπτυξη και τις δεσμεύσεις σας

$ git add .
$ git commit -m "IRA-TASK-ID: Περιγραφή εργασίας" #initial commit
$ git push origin feature-JIRA-TASK-ID

Ανοιχτό αίτημα έλξης

Επαναβάση και προετοιμασία για αίτηση έλξης

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # use -i flag for squash
$ git push -f origin feature-JIRA-TASK-ID 1TP65Χρησιμοποιήστε το προσεκτικά καθώς η σημαία -f αντικαθιστά το απομακρυσμένο αποθετήριο

Συγχώνευση αλλαγών και διαγραφή κλάδου

$ git checkout develop Ο κλάδος # θα πρέπει να συγχρονιστεί με τον κλάδο develop σε αυτό το στάδιο
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID

Απελευθερώσεις

$ git checkout master && git pull --rebase
$ git checkout develop && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P

Δημιουργία δέσμευσης έκδοσης

$ git add .
$ git commit -m "Όνομα προϊόντος M.M.P release" #initial commit
$ git push origin release-M.M.P

Ανοιχτό αίτημα έλξης

Συγχώνευση αλλαγών, απελευθέρωση και διαγραφή κλάδου

$ git checkout master Ο κλάδος # θα πρέπει να συγχρονιστεί με τον κλάδο master σε αυτό το στάδιο
$ git merge release-M.M.P
$ git tag -a M.M.P # το μήνυμα προσθήκης μπορεί να οριστεί μέσω της σημαίας -m
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P

Διόρθωση σφαλμάτων

$ git checkout release-M.M.P && git pull --rebase
$ git checkout -b bugfix-M.M.P

$ Δέσμευση διορθώσεων
$ git add .
$ git commit -m "Bugfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Ανοιχτό αίτημα έλξης

Συγχώνευση αλλαγών και διαγραφή κλάδου

$ git checkout release-M.M.P Ο κλάδος # θα πρέπει να συγχρονιστεί με τον τρέχοντα κλάδο έκδοσης σε αυτό το στάδιο
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
$ git branch -d bugfix-M.M.P
$ git push origin :bugfix-M.M.P

Hotfix

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P αντιπροσωπεύει την τρέχουσα έκδοση

$ Δέσμευση διορθώσεων
$ git add .
$ git commit -m "Hotfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Ανοιχτό αίτημα έλξης

Συγχώνευση αλλαγών, απελευθέρωση και διαγραφή κλάδων

$ git checkout master Ο κλάδος # θα πρέπει να συγχρονιστεί με τον τρέχοντα master σε αυτό το στάδιο
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # μήνυμα προσθήκης μπορεί να οριστεί μέσω της σημαίας -m
$ git push origin X.Y.(Z+1)
$ git push origin master
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git checkout develop && git merge master
$ git push origin develop

Διαβάστε περισσότερα:

• Οι καλές πρακτικές της Codest για την κατασκευή λογισμικού: CircleCI
• Πώς να δημιουργήσετε επεκτάσεις Google Chrome χρησιμοποιώντας τον στυλίσκο υποτίτλων Netflix;
• React: το πιο δημοφιλές πλαίσιο JavaScript