Przepływ pracy Gitflow
Gitflow to starszy przepływ pracy w systemie Git, który pierwotnie stanowił przełomową i nowatorską strategię zarządzania gałęziami Git. Gitflow stracił popularność na rzecz przepływów pracy opartych o gałąź główną, które obecnie uznaje się za najlepsze rozwiązania w zakresie nowoczesnego ciągłego tworzenia oprogramowania i praktyk DevOps. Korzystanie z Gitflow może również kłopotliwe w przypadku procesów CI/CD. Ten wpis opisujący szczegóły Gitflow zamieszczamy ze względów historycznych.
Czym jest Gitflow?
Gitflow jest alternatywnym modelem tworzenia gałęzi w Git, który obejmuje użycie gałęzi funkcji i wielu gałęzi podstawowych. Został on po raz pierwszy opublikowany i spopularyzowany przez Vincenta Driessena w witrynie nvie. W przeciwieństwie do tworzenia oprogramowania opartego o gałąź główną, Gitflow obejmuje większą liczbę dłuższych gałęzi i większe commity. W tym modelu programiści tworzą gałąź funkcji i opóźniają scalenie jej z gałęzią główną do momentu ukończenia pracy nad funkcją. Scalenie tak dłuższych gałęzi funkcji wymaga więcej współpracy i zwiększa ryzyko odchyleń od gałęzi głównej. Może również prowadzić do wprowadzenia sprzecznych aktualizacji.
Gitflow można używać w projektach, które mają zaplanowany cykl wydawania oraz do realizacji najlepszych praktyk DevOps w zakresie ciągłego dostarczania. Ten przepływ pracy nie wnosi żadnych nowych koncepcji ani poleceń oprócz tych, które są wymagane w przepływie pracy gałęzi funkcji. Zamiast tego przypisuje on bardzo konkretne role różnym gałęziom oraz definiuje sposób i czas ich interakcji. Oprócz gałęzi feature wykorzystuje on osobne gałęzie do przygotowywania, serwisowania i rejestrowania wydań. Naturalnie pozwala on wykorzystać wszystkie zalety przepływu pracy gałęzi funkcji, takie jak pull requesty, odizolowane eksperymenty i bardziej efektywna współpraca.
materiały pokrewne
Zaawansowany dziennik Git
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
Jak to działa
Gałęzie programistyczna i główna
Zamiast pojedynczej gałęzi main do rejestrowania historii projektu w tym przepływie pracy są wykorzystywane dwie gałęzie. W gałęzi main jest przechowywana historia oficjalnych wydań, natomiast gałąź develop służy do integrowania funkcji. Wygodnym rozwiązaniem jest również tagowanie wszystkich commitów w gałęzi main numerem wersji.
Pierwszym krokiem jest uzupełnienie domyślnej gałęzi main o gałąź develop. Prostym sposobem na to jest utworzenie przez jednego programistę pustej gałęzi develop lokalnie, a następnie wypchnięcie jej na serwer:
git branch develop
git push -u origin developTa gałąź będzie zawierała pełną historię projektu, a gałąź main będzie zawierała wersję skróconą. Teraz inni programiści powinni sklonować centralne repozytorium i utworzyć gałąź śledzącą gałąź develop.
W przypadku korzystania z biblioteki rozszerzeń git-flow wykonanie polecenia git flow init w odniesieniu do istniejącego repozytorium spowoduje utworzenie gałęzi develop:
$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
$ git branch
* develop
mainGałęzie funkcji
Krok 1. Utwórz repozytorium
Każda nowa funkcja powinna mieć własną gałąź, którą można wypchnąć do centralnego repozytorium na potrzeby utworzenia kopii zapasowej lub prowadzenia współpracy. Jednak gałęzie feature nie są tworzone jako odchodzące od gałęzi main, ale wykorzystują gałąź develop jako gałąź nadrzędną. Gdy funkcja jest gotowa, zostaje scalona z powrotem z gałęzią develop. Funkcje nigdy nie powinny wchodzić w bezpośrednie interakcje z gałęzią main.
Należy zauważyć, że gałęzie feature połączone z gałęzią develop są pod względem zamierzeń i celów tożsame z przepływem pracy gałęzi funkcji. Ale przepływ pracy Gitflow nie ogranicza się tylko do tego.
Gałęzie feature zasadniczo wyprowadza się z ostatniej gałęzi develop.
Tworzenie gałęzi funkcji
Bez rozszerzeń git-flow:
git checkout develop
git checkout -b feature_branchZ użyciem rozszerzeń git-flow:
git flow feature start feature_branchKontynuuj pracę, korzystając z Git tak jak zwykle.
Kończenie gałęzi funkcji
Po zakończeniu prac programistycznych związanych z funkcją kolejnym krokiem jest scalenie gałęzi feature_branch z gałęzią develop.
Bez rozszerzeń git-flow:
git checkout develop
git merge feature_branchZ użyciem rozszerzeń git-flow:
git flow feature finish feature_branchGałęzie wydań
Gdy w gałęzi develop znajdzie się dostateczna liczba funkcji, aby przeprowadzić wydanie (lub gdy zbliża się wstępnie ustalona data wydania), robi się podział w celu utworzenia gałęzi release odchodzącej od gałęzi develop. Utworzenie tej gałęzi rozpoczyna kolejny cykl wydawania, dlatego po tym czasie nie można dodawać żadnych nowych funkcji. W tej gałęzi można jedynie wprowadzać poprawki błędów, generować dokumentację oraz wykonywać inne zadania związane z wydawaniem. Gdy wszystko będzie gotowe do wydania, gałąź release jest scalana z gałęzią main i tagowana numerem wersji. Dodatkowo należy scalić ją z powrotem z gałęzią develop, w której od momentu wydania mogły zostać wprowadzone jakieś zmiany.
Zastosowanie dedykowanej gałęzi do przygotowywania wydań umożliwia jednemu zespołowi dopracowywanie bieżącego wydania, podczas gdy inny zespół może nadal pracować nad funkcjami do kolejnego wydania. Pozwala to również podzielić prace programistyczne na wyraźnie zdefiniowane fazy (np. można z łatwością powiedzieć: „W tym tygodniu przygotowujemy wersję 4.0” i faktycznie zobaczyć to w strukturze repozytorium).
Tworzenie gałęzi release jest kolejną prostą operacją tworzenia gałęzi. Podobnie jak gałęzie feature gałęzie release są oparte na gałęzi develop. Nową gałąź release można utworzyć za pomocą opisanych poniżej metod.
Bez rozszerzeń git-flow:
git checkout develop
git checkout -b release/0.1.0Z użyciem rozszerzeń git-flow:
$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'Gdy wydanie będzie gotowe do dostarczenia, zostanie scalone z gałęzią main i develop, a następnie gałąź release zostanie usunięta. Ponowne scalenie z gałęzią develop jest ważne, ponieważ do gałęzi release mogły zostać dodane krytyczne aktualizacje, które muszą być dostępne dla nowych funkcji. Jeśli Twoja organizacja kładzie nacisk na przegląd kodu, byłby to doskonały moment na pull request.
Aby zakończyć gałąź release, użyj poniższych metod:
Bez rozszerzeń git-flow:
git checkout main
git merge release/0.1.0Lub z użyciem rozszerzeń git-flow:
git flow release finish '0.1.0'Gałęzie poprawek
Gałęzie serwisowe lub hotfix umożliwiają szybkie wprowadzanie poprawek do wydań produkcyjnych. Gałęzie hotfix są bardzo podobne do gałęzi release oraz feature, jednak opierają się na gałęzi main, a nie develop. Są to jedyne gałęzie, które powinny wyprowadzane bezpośrednio od gałęzi main. Gdy tylko poprawka będzie gotowa, należy ją scalić z gałęziami main i develop (lub bieżącą gałęzią release), a gałąź main należy otagować zaktualizowanym numerem wersji.
Dzięki dedykowanej linii prac programistycznych dotyczących poprawek błędów zespół może rozwiązywać problemy bez przerywania pozostałej części przepływu pracy albo oczekiwania na kolejny cykl wydawania. Gałęzie serwisowe można traktować jako doraźne gałęzie release, które współpracują bezpośrednio z gałęzią main. Gałąź hotfix można utworzyć przy użyciu następujących metod:
Bez rozszerzeń git-flow:
git checkout main
git checkout -b hotfix_branchZ użyciem rozszerzeń git-flow:
$ git flow hotfix start hotfix_branchPodobnie jak w przypadku kończenia gałęzi release, gałąź hotfix jest scalana z gałęziami main i develop.
git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch$ git flow hotfix finish hotfix_branchPrzykład
Poniżej przedstawiono kompletny przykład ilustrujący przepływ gałęzi funkcji. Założono w nim, że mamy konfigurację repozytorium z gałęzią main.
git checkout main
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branchOprócz przepływu dla gałęzi feature i release przedstawiamy również przykład przepływu dla gałęzi hotfix:
git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branchPodsumowanie
W tej części omówiliśmy przepływ pracy Gitflow. Gitflow jest jednym z wielu stylów przepływu pracy Git, z których może korzystać Twój zespół.
Najważniejsze wnioski na temat przepływu Gitflow:
- Ten przepływ pracy doskonale sprawdza się jako przepływ pracy nad oprogramowaniem oparty na wydaniach.
- Gitflow oferuje dedykowany kanał do wprowadzania poprawek w wersji produkcyjnej.
Ogólny proces Gitflow jest następujący:
1. Utworzenie gałęzi develop wyprowadzonej z gałęzi main.
2. Utworzenie gałęzi release wyprowadzonej z gałęzi develop.
3. Utworzenie gałęzi feature wyprowadzonej z gałęzi develop.
4. Po zakończeniu prac nad gałęzią feature scalenie jej z gałęzią develop.
5. Gdy gałąź release jest gotowa, scalenie jej z gałęziami develop i main.
6. W razie wykrycia problemu w gałęzi main utworzenie gałęzi hotfix wyprowadzonej z gałęzi main.
7. Po zakończeniu prac nad gałęzią hotfix scalenie jej z gałęziami develop i main.
W dalszej kolejności zapoznaj się z przepływem pracy z podziałem lub odwiedź stronę z porównaniem przepływów pracy.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Blog Bitbucket
Ścieżka szkoleniowa DevOps
