Niniejszy dokument został napisany w celu ujednolicenia wewnętrznych zasad GitFlow w firmie. Metoda ta nie wprowadza czystego GitFlow, ponieważ jest mieszanką zarówno GitFlow, jak i GitLab Flow, z najlepszymi praktykami firmy wypracowanymi przez wiele lat. Pomaga ona w utrzymaniu czystej i czytelnej historii repozytorium oraz lepszej kontroli nad wprowadzanymi zmianami i projekt cykl życia.

Inicjalizacja repozytorium

Po zainicjowaniu repozytorium utwórz plik rozwijać się i mistrz jeśli nie została dołączona domyślnie. Gałąź deweloperska powinna zawierać kod która jest lustrzanym odbiciem gałęzi master z dodanymi nowymi funkcjami. Gałąź master zawiera stabilną wersję kodu, reprezentującą stan produkcyjny. Obie mają nieskończony czas życia i w porównaniu do innych gałęzi w Git Flow, nigdy nie zostaną usunięte. Skonfiguruj odpowiednie reguły ochrony: wymagać recenzji pull requestów przed scaleniem i wymagać sprawdzenia stanu przed scaleniem. Można również rozważyć zezwolenie tylko wybranym zespół aby scalić zmiany do wersji master.

$ git init
$ git commit --allow-empty -m "Początkowe zatwierdzenie"
$ git checkout -b develop master

UWAGA: Czasami ważne jest, aby projekt dodał więcej nieskończonych gałęzi, na przykład w celu reprezentowania dostępnych środowisk. Należy jednak zachować "zasadę dwóch", jeśli to możliwe.

Gałęzie funkcji

Rozpoczynając pracę z daną funkcją, najpierw upewnij się, że posiadasz swoje rozwijać się gałąź zsynchronizowana.

 $ git checkout develop && git pull --rebase

Następnie przejdź do gałęzi funkcji. Nazwij ją odpowiednio do podanego schematu: feature-JIRA-TASK-ID Można też złamać tę zasadę i nazwać ją inaczej. W takim przypadku należy upewnić się, że nie koliduje ona z wzorcami zarezerwowanymi dla wydania, poprawki, poprawki błędu, rozwoju lub gałęzi głównej. Zachowanie identyfikatorów zadań JIRA pomoże ci efektywniej zarządzać gałęziami funkcji.

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

Ta gałąź powinna istnieć tak długo, jak dana funkcja jest rozwijana, a następnie scalana z gałęzią nadrzędną. Aby zatwierdzić gałąź lokalną, wykonaj poniższe polecenie:

 $ git add .
 $ git commit -m "JIRA-TASK-ID: Opis zadania"

Zaleca się dodawanie kolejnych commitów do lokalnej gałęzi, zgodnie z zasadą "Commit early and often". Jednak ostatecznie muszą one zostać zgniecione w jedno zatwierdzenie reprezentujące zadanie JIRA. Częste zatwierdzanie pomoże ci zarządzać historią rozwoju. Gdy funkcja jest gotowa, nadszedł czas, aby otworzyć Pull Request w celu rozwinięcia gałęzi. Najpierw możesz wypchnąć swoją lokalną gałąź, jeśli nie została wypchnięta zbyt daleko:

 $ git push origin feature-JIRA-TASK-ID

Gdy gałąź będzie gotowa, otwórz pull request na GitHub, postępując zgodnie z tym artykułem: https://help.github.com/en/articles/creating-a-pull-request

Przed otwarciem pull requesta należy upewnić się, że spełnione są poniższe warunki:

• a właściwy opis został podany - zazwyczaj połączyć zadanie JIRA, ale możesz również dołączyć przydatne informacje związane z bieżącym kodem
• CircleCI kroki zostały zaliczone pomyślnie
• twój członkowie zespołu zostali przydzieleni - Dobrą praktyką jest uwzględnienie wszystkich członków zespołu jako cesjonariuszy.
• w wybrano recenzentów - Liczba recenzentów zależy od zespołu
• kod jest gotowy do sprawdzenia - spójrz ostatni raz na swój kod, zastanów się jeszcze raz, czy zostało coś do refaktoryzacji, przetestuj go lokalnie i upewnić się, że jest gotowy do dalszych kroków.
• są brak konfliktów scalania i gałąź jest aktualna z develop - Jeśli są jakieś, rozwiąż je najpierw

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # użyj flagi -i dla squasha
$ git push -f origin feature-JIRA-TASK-ID 1TP63Używaj tego ostrożnie, ponieważ flaga -f nadpisuje zdalne repozytorium

• zachować tylko ważne zatwierdzenia - Każde zatwierdzenie powinno być reprezentowane na przykład przez zadanie JIRA, JIRA-TASK-ID: Konfiguracja nowej funkcji; inni powinni być zgnieciony podczas ponownego bazowania twoja gałąź z gałęzią deweloperską
• masz wybrano właściwy oddział docelowy
• nie zapomnij zmienić status zadania JIRA

Scalanie gałęzi funkcji

Nadszedł czas, aby scalić zmiany do gałęzi deweloperskiej:

• żądanie ściągnięcia zostało zatwierdzone przez wybranych członków zespołu
• Wszystkie testy zakończyły się pomyślnie
• nie ma konfliktów scalania, a historia zatwierdzeń wygląda w porządku

Może to zrobić kierownik projektu lub twórca funkcji. Aby wykonać scalenie, wykonaj następujące kroki:

 $ 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

Teraz można zmienić status zadania JIRA.

Zwolnienia

Gałęzie wydań powinny być tworzone przez osobę odpowiedzialną za bieżące wydanie. Zazwyczaj wydania są tworzone okresowo, na przykład zgodnie z procedurą sprint cykl życia.

Wersjonowanie semantyczne

Nadanie gałęzi wydania odpowiedniej nazwy i odpowiadającego jej tagu nie jest łatwym zadaniem na samym początku. Dobrą praktyką jest rozpoczęcie korzystania z semantycznego wersjonowania (https://semver.org/), co pozwala na lepszą kontrolę i ułatwia czytanie historii git. Ciąg wersji jest konstruowany zgodnie ze schematem MAJOR.MINOR.PATCH:

• MAJOR - zmiana reprezentująca niekompatybilne zmiany API
• MINOR - dodawanie nowych funkcji w sposób kompatybilny wstecz.
• PATCH - dodanie poprawek błędów kompatybilnych wstecz

Możesz także użyć specjalnych sufiksów, takich jak te reprezentujące gałęzie beta lub starsze, lub utworzyć wersje przedpremierowe. W takim przypadku należy je odpowiednio nazwać, np. 1.1.0-beta.4, 1.1.0-beta.5 lub 1.1.0-alpha.

Udostępnianie

Gałąź release powinna być dzieckiem gałęzi develop i może zawierać tylko commity związane z poprawkami błędów.

Nazwa gałęzi powinna być oparta na wersji wydania, z prefiksem release-: release-MAJOR.MINOR.PATCH. Gałąź wydania powinna być w pełni przetestowane zarówno automatycznie, jak i ręcznie na środowisko przejściowe. Jeśli pojawią się błędy, jest to ostatnia okazja do wprowadzenia odpowiednich poprawek i ponownego uruchomienia całego procesu, o ile nie zostanie on pozytywnie sprawdzony i gotowy do dalszego przetwarzania. Następnie należy wypchnąć zatwierdzenie wydania, ze zmianami bieżącego ciągu wersji wydania w plikach, takich jak package.json. Powinno to mieć również wpływ na plik CHANGELOG.md. Pomoże to śledzić wszystkie zmiany przed właściwym wydaniem i przygotować zawartość do wydania GitHub po zakończeniu procesu scalania. Aktualizacja pojedynczego pliku powinna składać się ze wszystkich zmian w wydaniu pogrupowanych w trzy kategorie: funkcje, poprawki i konserwacja.

W pierwszym kroku należy jednak upewnić się, że obie gałęzie develop i master są aktualne.

 $ 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 "Produkt Nazwa M.M.P release"
 $ git push origin release-M.M.P

W tym momencie można zdecydować się na utworzenie kolejnego pull requesta do mastera z gałęzią release. Dobrym pomysłem może być uruchomienie dodatkowego sprawdzenia, czy wszystkie testy przeszły pomyślnie na zdalnej maszynie.

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # dodatkowa wiadomość może być ustawiona za pomocą flagi -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

Następnie należy przejść do strony wydań GitHub i nacisnąć przycisk "Draft new release". W wyświetlonym formularzu należy wybrać tag bieżącej wersji, ustawić tytuł wydania podobny do commitu wydania (Product Name M.M.P release) oraz odpowiedni opis, bazujący na pliku CHANGELOG.md. W przypadku projektów publicznych opis powinien zawierać listę wszystkich PR zawartych w bieżącym wydaniu.

W przypadku, gdy niektóre poprawki błędów zostały zastosowane w gałęzi wydania, należy upewnić się, że gałąź deweloperska została zaktualizowana:

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

Poprawki na gorąco i poprawki błędów

Główną różnicą między błędem a poprawką jest ich docelowa gałąź.

Poprawka błędu

Poprawki błędów powinny łatać gałęzie wydań jako jedyną formę aktualizacji kodu przed scaleniem go do wersji master. Najpierw utwórz gałąź z bieżącej gałęzi funkcji. Upewnij się, że masz ją lokalnie zaktualizowaną.

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

Następnie zatwierdź niezbędne zmiany. Po zakończeniu procesu utwórz żądanie ściągnięcia i skieruj je do gałęzi wydania. Postępuj zgodnie ze wskazówkami z sekcji gałęzi funkcji. Ostateczny tytuł zatwierdzenia powinien być zgodny z podanym schematem: "Bugfix M.M.P: Problem essence fix". Gdy pull request zostanie zatwierdzony, nadejdzie czas na scalenie go z bieżącym wydaniem.

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

Hotfix

Aby wykonać poprawkę hotfix na gałęzi głównej, należy wykonać bardzo podobne kroki jak w przypadku poprawki błędu, pamiętając, że gałęzią docelową jest teraz gałąź główna.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P reprezentuje bieżące wydanie

Następnie postępuj zgodnie ze zwykłymi krokami rozwoju, a po zakończeniu procesu utwórz żądanie ściągnięcia z gałęzią główną jako celem. Należy pamiętać, że ostateczne zatwierdzenie powinno być zgodne z podanym schematem "Hotfix X.Y.(Z + 1): Problem essence fix". Gdy każdy punkt kontrolny przejdzie pomyślnie, wykonaj scalenie z gałęzią master. Kroki te różnią się od tych przedstawionych dla poprawki błędu, ponieważ musimy podnieść aktualną wersję wydania.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # dodatkowy komunikat można ustawić za pomocą flagi -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

Ściągawka

Repozytorium początkowe

 $ git init
 $ git commit --allow-empty -m "Początkowe zatwierdzenie"
 $ git checkout -b develop master
 $ git push origin develop
 $ git push origin master

Cechy

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

Rozpocznij rozwój i zatwierdzenia

$ git add .
$ git commit -m "IRA-TASK-ID: Opis zadania" #initial commit
$ git push origin feature-JIRA-TASK-ID

Otwarte żądanie ściągnięcia

Rebase i przygotowanie do pull requesta

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # użyj flagi -i dla squasha
$ git push -f origin feature-JIRA-TASK-ID 1TP63Używaj tego ostrożnie, ponieważ flaga -f nadpisuje zdalne repozytorium

Scal zmiany i usuń gałąź

$ git checkout develop # gałąź powinna być zsynchronizowana z gałęzią develop na tym etapie.
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID

Zwolnienia

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

Utwórz zatwierdzenie wydania

$ git add .
$ git commit -m "Nazwa produktu M.M.P release" #initial commit
$ git push origin release-M.M.P

Otwarte żądanie ściągnięcia

Scalanie zmian, wydanie i usunięcie gałęzi

$ git checkout master # gałąź powinna być zsynchronizowana z gałęzią master na tym etapie
$ git merge release-M.M.P
$ git tag -a M.M.P # dodatkowa wiadomość może być ustawiona za pomocą flagi -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

Poprawka błędu

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

$ Commit fixes
$ git add .
$ git commit -m "Bugfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Otwarte żądanie ściągnięcia

Scal zmiany i usuń gałąź

$ git checkout release-M.M.P Gałąź # powinna być zsynchronizowana z bieżącą gałęzią wydania na tym etapie.
$ 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 reprezentuje bieżące wydanie

$ Commit fixes
$ git add .
$ git commit -m "Hotfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Otwarte żądanie ściągnięcia

Scalanie zmian, wydawanie i usuwanie gałęzi

$ git checkout master # gałąź powinna być zsynchronizowana z bieżącym master na tym etapie
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # dodatkowa wiadomość może być ustawiona za pomocą flagi -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

Czytaj więcej:

• Dobre praktyki Codest dotyczące tworzenia oprogramowania: CircleCI
• Jak tworzyć rozszerzenia Google Chrome przy użyciu stylera napisów Netflix?
• React: najpopularniejsza struktura JavaScript