Git
Analiza rodzajów przepływów pracy

Uwagi

Gitflow Workflow

Gitflow, pierwotnie zaproponowany przez Vincenta Driessena , jest procesem programistycznym wykorzystującym git i kilka wstępnie zdefiniowanych gałęzi. Można to postrzegać jako szczególny przypadek przepływu pracy gałęzi cech .

Ideą tego jest posiadanie oddzielnych gałęzi zarezerwowanych dla określonych części w fazie rozwoju:

• master oddział jest zawsze najnowsza kod produkcji. Kod eksperymentalny nie należy tutaj.
• gałąź develop zawiera wszystkie najnowsze zmiany . Te zmiany rozwojowe mogą być praktycznie wszystkim, ale większe funkcje są zastrzeżone dla ich własnych oddziałów. Kod tutaj jest zawsze opracowywany i łączony w release przed wydaniem / wdrożeniem.
• gałęzie hotfix służą do drobnych poprawek błędów, które nie mogą czekać do następnej wersji. gałęzie hotfix wychodzą z master i są ponownie łączone w master i develop .
• gałęzie release są używane do wydawania nowych wersji od develop do master . Wszelkie zmiany wprowadzane w ostatniej chwili, takie jak podskakujące numery wersji, są wprowadzane w gałęzi wydania, a następnie łączone z powrotem w master i develop . Wdrażając nową wersję, master powinien być oznaczony bieżącym numerem wersji (np. Przy użyciu wersji semantycznej ) w celu odniesienia w przyszłości i łatwego wycofania.
• gałęzie feature są zarezerwowane dla większych funkcji. Są one specjalnie opracowywane w wyznaczonych oddziałach i zintegrowane z develop po zakończeniu. Dedykowane gałęzie feature pomagają w oddzielnym opracowywaniu i umożliwiają wdrażanie wykonanych funkcji niezależnie od siebie.

Wizualna reprezentacja tego modelu:

Oryginalna reprezentacja tego modelu:

Przepływ pracy

Ten typ przepływu pracy różni się zasadniczo od innych wymienionych w tym temacie. Zamiast jednego scentralizowanego repo, że wszyscy deweloperzy mają dostęp do, każdy deweloper ma jego / jej własne repo, który jest rozdwojony od głównego repo. Zaletą tego jest to, że programiści mogą publikować własne repozytoria zamiast repozytorium udostępnionego, a opiekun może w razie potrzeby zintegrować zmiany z repozytoriów repozytoriów z oryginałem.

Wizualna reprezentacja tego przepływu pracy jest następująca:

Scentralizowany przepływ pracy

Z tego podstawowego modelu workflow, A master gałąź zawiera wszystkie aktywne rozwoju. Współtwórcy będą musieli być szczególnie pewni, że wprowadzą najnowsze zmiany przed dalszym rozwojem, ponieważ ta gałąź będzie się szybko zmieniać. Każdy ma dostęp do tego repozytorium i może zatwierdzać zmiany bezpośrednio w gałęzi master.

Wizualna reprezentacja tego modelu:

Jest to klasyczny paradygmat kontroli wersji, na którym zbudowano starsze systemy, takie jak Subversion i CVS. Oprogramowanie działające w ten sposób nazywane jest scentralizowanymi systemami kontroli wersji lub CVCS. Chociaż Git jest w stanie działać w ten sposób, istnieją znaczące wady, takie jak konieczność poprzedzania każdego ściągania scaleniem. Zespół może bardzo pracować w ten sposób, ale ciągłe rozwiązywanie konfliktów scalania może ostatecznie pochłonąć wiele cennego czasu.

Właśnie dlatego Linus Torvalds stworzył Gita nie jako CVCS, ale raczej jako DVCS lub rozproszony system kontroli wersji , podobny do Mercurial. Zaletą tego nowego sposobu robienia rzeczy jest elastyczność pokazana w innych przykładach na tej stronie.

Przepływ pracy gałęzi funkcji

Podstawową ideą przepływu pracy gałęzi cech jest to, że cały rozwój funkcji powinien odbywać się w gałęzi dedykowanej zamiast gałęzi master . Ta enkapsulacja ułatwia wielu programistom pracę nad określoną funkcją bez zakłócania głównej bazy kodu. Oznacza to również master oddziału nie będzie zawierała złamany kod, co jest ogromną zaletą dla ciągłych środowiskach integracyjnych.

Hermetyzacja rozwoju funkcji umożliwia także wykorzystanie żądań ściągania, które są sposobem na zainicjowanie dyskusji wokół gałęzi. Dają innym programistom możliwość podpisania się na funkcji, zanim zostanie ona zintegrowana z oficjalnym projektem. Lub jeśli utkniesz w środku funkcji, możesz otworzyć żądanie ściągnięcia, prosząc o sugestie od swoich współpracowników. Chodzi o to, że prośby o pociągnięcie sprawiają, że twój zespół może bardzo łatwo komentować swoje prace.

na podstawie samouczków Atlassian .

GitHub Flow

Popularny w wielu projektach open source, ale nie tylko.

Główny oddział określonej lokalizacji (Github, Gitlab, Bitbucket, lokalny serwer) zawiera najnowszą wersję do wysyłki. Dla każdej nowej funkcji / poprawki błędu / zmiany architektonicznej każdy programista tworzy gałąź.

Zmiany zachodzą w tej gałęzi i mogą być omówione w żądaniu ściągnięcia, recenzji kodu itp. Po zaakceptowaniu zostają scalone z gałęzią główną.

Pełny przepływ Scott Chacon:

• Wszystko w gałęzi master jest możliwe do wdrożenia
• Aby pracować nad czymś nowym, utwórz opisowo nazwaną gałąź off of master (tj .: new-oauth2-scopes)
• Zaangażuj się w tę gałąź lokalnie i regularnie wypychaj swoją pracę do tej samej gałęzi o nazwie na serwerze
• Jeśli potrzebujesz informacji zwrotnej lub pomocy lub uważasz, że oddział jest gotowy do scalenia, otwórz żądanie ściągnięcia
• Po sprawdzeniu i wylogowaniu się przez użytkownika z funkcji możesz połączyć ją w master
• Po scaleniu i przekazaniu do „master”, możesz i powinieneś natychmiast wdrożyć

Oryginalnie prezentowany na osobistej stronie internetowej Scott Chacon .

Zdjęcie dzięki uprzejmości GitHub Flow