Heading

Gitflow Workflow to przepływ pracy Git, który pomaga w ciągłym rozwoju oprogramowania i wdrażaniu praktyk DevOps. Został on po raz pierwszy opublikowany i spopularyzowany przez Vincenta Driessena na nvie. Przepływ pracy Gitflow definiuje ścisły model rozgałęziania zaprojektowany wokół wydania projektu. Zapewnia to solidne ramy do zarządzania większymi projektami.

Gitflow idealnie nadaje się do projektów, które mają zaplanowany cykl wydawniczy oraz do najlepszych praktyk DevOps – ciągłego dostarczania. Ten przepływ pracy nie dodaje żadnych nowych pojęć ani poleceń poza tymi, które są wymagane przez przepływ pracy Feature Branch. Zamiast tego, przypisuje on bardzo konkretne role różnym gałęziom oraz definiuje, jak i kiedy powinny one ze sobą współdziałać. Oprócz gałęzi feature, wykorzystuje poszczególne gałęzie do przygotowywania, utrzymywania i rejestrowania wydań. Oczywiście, można również wykorzystać wszystkie korzyści płynące z Feature Branch Workflow: pull requesty, izolowane eksperymenty i bardziej efektywną współpracę.

Początek

Gitflow jest tak naprawdę tylko abstrakcyjną ideą przepływu pracy Git. Oznacza to, że dyktuje on, jakiego rodzaju gałęzie należy utworzyć i jak je połączyć. Poniżej poruszymy kwestię przeznaczenia gałęzi. Zestaw narzędzi git-flow jest rzeczywistym narzędziem wiersza poleceń, które posiada proces instalacji. Proces instalacji git-flow jest prosty. Pakiety dla git-flow są dostępne w wielu systemach operacyjnych. Na systemach OSX, możesz wykonać brew install git-flow. Na systemach Windows będziesz musiał pobrać i zainstalować git-flow. Po zainstalowaniu git-flow możesz użyć go w swoim projekcie wykonując git flow init. Git-flow jest opakowaniem wokół Git. Polecenie git flow init jest rozszerzeniem domyślnego polecenia git init i nie zmienia niczego w twoim repozytorium poza tworzeniem dla ciebie gałęzi.

Jak to działa

Gałęzie Develop i Master

Zamiast pojedynczej master gałęzi, ten przepływ pracy używa dwóch gałęzi do zapisywania historii projektu. Gałąź master przechowuje oficjalną historię wydania, a gałąź develop służy jako gałąź integracyjna dla funkcji. Wygodnie jest również oznaczać wszystkie commity w gałęzi master numerem wersji.

Pierwszym krokiem jest uzupełnienie domyślnej gałęzi master o gałąź develop. Prostym sposobem na to jest utworzenie przez jednego dewelopera pustej gałęzi develop lokalnie i przesłanie jej na serwer:

git branch develop
git push -u origin develop

Ta gałąź będzie zawierała pełną historię projektu, podczas gdy master będzie zawierała skróconą wersję. Inni deweloperzy powinni teraz sklonować centralne repozytorium i utworzyć gałąź śledzącą dla develop.

Gdy używamy biblioteki rozszerzającej git-flow, wykonanie git flow init na istniejącym repo utworzy gałąź 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: 
Branch name for "next release" development: 
How to name your supporting branch prefixes?
Feature branches? 
Release branches? 
Hotfix branches? 
Support branches? 
Version tag prefix? 
$ git branch
* develop
master

Gałęzie cech

Każda nowa cecha powinna rezydować w swojej własnej gałęzi, która może zostać wypchnięta do centralnego repozytorium w celu wykonania kopii zapasowej/współpracy. Ale zamiast rozgałęziać się od master, gałęzie feature używają develop jako swojej gałęzi nadrzędnej. Kiedy funkcjonalność jest ukończona, zostaje scalona z powrotem do rozwoju. Cechy nigdy nie powinny wchodzić w bezpośrednią interakcję z master.

Zauważ, że feature gałęzie w połączeniu z develop gałęzią jest, dla wszystkich intencji i celów, przepływem pracy Feature Branch Workflow. Ale, przepływ pracy Gitflow nie kończy się na tym.

Feature gałęzie są generalnie tworzone poza najnowszą develop gałęzią.

Tworzenie gałęzi funkcji

Bez rozszerzeń git-flow:

git checkout develop
git checkout -b feature_branch

Gdy używamy rozszerzenia git-flow:

git flow feature start feature_branch

Kontynuuj swoją pracę i używaj Gita tak jak normalnie.

Ukończenie gałęzi funkcji

Kiedy skończysz pracę nad rozwojem funkcji, następnym krokiem jest scalenie feature_branch do develop.

Bez rozszerzeń git-flow:

git checkout develop
git merge feature_branch

Używając rozszerzeń git-flow:

git flow feature finish feature_branch

Odgałęzienia wydania

Gdy develop zdobędzie wystarczającą ilość funkcji do wydania (lub zbliża się wcześniej ustalona data wydania), rozwidlamy gałąź release z develop. Utworzenie tej gałęzi rozpoczyna następny cykl wydania, więc żadne nowe funkcje nie mogą być dodawane po tym momencie – tylko poprawki błędów, tworzenie dokumentacji i inne zadania związane z wydaniem powinny być wykonywane w tej gałęzi. Gdy gałąź release będzie gotowa do wysłania, zostanie połączona z master i oznaczona numerem wersji. Dodatkowo, powinien zostać scalony z powrotem do gałęzi develop, która mogła się rozwinąć od czasu rozpoczęcia wydania.

Używanie dedykowanej gałęzi do przygotowywania wydań umożliwia jednemu zespołowi dopracowanie bieżącego wydania, podczas gdy inny zespół kontynuuje pracę nad funkcjami do następnego wydania. Tworzy to również dobrze zdefiniowane fazy rozwoju (np. łatwo jest powiedzieć: „W tym tygodniu przygotowujemy wersję 4.0,” i faktycznie zobaczyć to w strukturze repozytorium).

Tworzenie gałęzi release jest kolejną prostą operacją rozgałęzienia. Podobnie jak feature branches, release branches są oparte na develop branch. Nową gałąź release można utworzyć za pomocą następujących metod.

Bez rozszerzeń git-flow:

git checkout develop
git checkout -b release/0.1.0

W przypadku korzystania z rozszerzeń git-flow:

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

Gdy wydanie jest gotowe do wysyłki, zostanie scalone do master i develop, a następnie gałąź release zostanie usunięta. Ważne jest, aby scalić z powrotem do develop, ponieważ krytyczne aktualizacje mogły zostać dodane do gałęzi release i muszą być dostępne dla nowych funkcji. Jeśli Twoja organizacja kładzie nacisk na code review, to byłoby to idealne miejsce na pull request.

Aby ukończyć gałąź release, użyj następujących metod:

Bez rozszerzeń git-flow:

git checkout master 
git merge release/0.1.0

Albo z rozszerzeniem git-flow:

git flow release finish '0.1.0'

Gałęzie hotfix

Gałęzie maintenance lub "hotfix” gałęzie są używane do szybkiego łatania wydań produkcyjnych. Oddziały Hotfix są bardzo podobne do oddziałów release i feature z wyjątkiem tego, że są oparte na master zamiast develop. To jest jedyna gałąź, która powinna rozwidlać się bezpośrednio z master. Gdy tylko poprawka zostanie ukończona, powinna zostać scalona zarówno do master jak i develop (lub obecnej gałęzi release), a master powinien zostać oznaczony zaktualizowanym numerem wersji.

Posiadanie dedykowanej linii rozwoju dla poprawek błędów pozwala Twojemu zespołowi zająć się problemami bez przerywania reszty przepływu pracy lub czekania na następny cykl wydania. Możesz myśleć o gałęziach serwisowych jak o gałęziach ad hoc release, które pracują bezpośrednio z master. Gałąź hotfix można utworzyć przy użyciu następujących metod:

Bez rozszerzeń git-flow:

git checkout master
git checkout -b hotfix_branch

Przy użyciu rozszerzeń git-flow:

$ git flow hotfix start hotfix_branch

Podobnie jak w przypadku kończenia gałęzi release, gałąź hotfix zostaje połączona zarówno z master jak i develop.

git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

$ git flow hotfix finish hotfix_branch

Przykład

Pełny przykład demonstrujący Feature Branch Flow jest następujący. Zakładając, że mamy skonfigurowane repo z gałęzią master.

git checkout master
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout master
git merge develop
git branch -d feature_branch

Dodatkowo do przepływu feature i release, przykład hotfix jest następujący:

git checkout master
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout master
git merge hotfix_branch

Podsumowanie

W tym miejscu omówiliśmy przepływ pracy Gitflow. Gitflow jest jednym z wielu stylów przepływów pracy Git, które Ty i Twój zespół możecie wykorzystać.

Kilka kluczowych informacji, które warto wiedzieć o Gitflow to:

• Przepływ ten jest świetny dla przepływu pracy oprogramowania opartego na wydaniach.
• Gitflow oferuje dedykowany kanał dla hotfixów do produkcji.

Ogólny przepływ Gitflow to:

1. A develop branch is created from master
2. A release branch is created from develop
3. Feature gałęzie są tworzone z develop
4. Gdy feature jest kompletny, jest on scalany do develop gałęzi
5. Gdy release gałąź jest wykonywana, jest ona łączona z develop i master
6. Jeśli wykryto błąd w master, tworzona jest hotfixmaster
7. Jak tylko hotfix zostanie ukończony, jest on scalany zarówno z develop jak i master

Następnie, dowiedz się więcej na temat przepływu pracy Forking lub odwiedź naszą stronę porównania przepływów pracy.