Praca zespołowa bez zamieszania: zrozumienie strategii rozgałęziania w Git

Wstęp

Git stał się de facto standardem branżowym kontroli wersji przy tworzeniu oprogramowania. Aby dowiedzieć się czym jest git i jak zacząć, przeczytaj najpierw mój artykuł na ten temat. Czytałeś to? Świetnie, idziemy dalej! Czy nam się to podoba, czy nie, instrument stworzony przez Linusa Towaldsa nie przejdzie na emeryturę. Dlatego warto porozmawiać o tym, jak rozproszone zespoły działają w git i jaką strategię rozgałęziania wybrać w tym celu. I wcale nie jest to pytanie bezczynne. Często w sytuacji, gdy tworzony jest nowy zespół programistów, którzy nie współpracowali ze sobą, strategia rozgałęzienia jest jedną z pierwszych rzeczy, które należy podjąć. I znajdą się ludzie, którzy będą mieli pianę z ust, żeby udowodnić, że jedna strategia jest lepsza od drugiej. Dlatego też chcę Państwu przekazać informacje o tym, czym one w ogóle są.

Czy strategie rozgałęziania są konieczne?

Ale są i są potrzebni. Bo jeśli w zespole się na coś nie zgodzicie, to okazuje się, że każdy zrobi, co mu się podoba:

• pracować w branży, w której chce;
• połączyć się z innymi gałęziami, których chce;
• usuń niektóre gałęzie;
• tworzyć nowe;
• i tak dalej – każdy z członków zespołu znajduje się w niekontrolowanym przepływie.

Dlatego poniżej znajdują się trzy strategie. Iść!

Strategia GitHub Flow

Strategia rozgałęziania, niezależnie od tego, jak dziwna może to być, jest preferowana w GitHubie :) Dołączony jest do niej zbiór zasad , których należy przestrzegać:

1. Kod w gałęzi master musi być nienaruszony i gotowy do wdrożenia w dowolnym momencie (tzn. nie można tam umieścić kodu, który uniemożliwi zbudowanie projektu i wdrożenie go na serwerze).
2. Kiedy planujesz pracować nad nową funkcjonalnością, musisz utworzyć nową gałąź (gałąź funkcji) w oparciu o gałąź główną i nadać jej znaczącą nazwę. Zatwierdź swój kod lokalnie i regularnie wypychaj zmiany do tej samej gałęzi w zdalnym repozytorium.
3. Otwórz Pull-Request (możesz przeczytać tutaj , co to jest pull-request ), gdy masz wyraźne przeczucie, że praca jest gotowa i można ją połączyć z gałęzią główną (lub jeśli nie jesteś pewien, ale chcesz uzyskać informację zwrotną na ten temat Praca skończona).
4. Po zatwierdzeniu nowej funkcji w żądaniu ściągnięcia można ją połączyć z gałęzią główną.
5. Kiedy zmiany zostaną scalone w gałęzi głównej, należy je natychmiast wdrożyć na serwerze.

Według GitHub Flow okazuje się, że zanim zaczniesz pracować nad czymś nowym, czy to poprawką, czy nową funkcjonalnością, musisz stworzyć nową gałąź na podstawie mastera i nadać jej odpowiednią nazwę. Następnie rozpoczynają się prace nad wdrożeniem. Musisz stale przesyłać zatwierdzenia na zdalny serwer o tej samej nazwie. Kiedy zrozumiesz, że wszystko jest gotowe, musisz utworzyć żądanie ściągnięcia w gałęzi master. Następnie co najmniej jedna, a jeszcze lepiej dwie osoby powinny spojrzeć na ten kod i kliknąć Zatwierdź. Zwykle kierownik zespołu projektu i ktoś inny muszą się temu przyjrzeć, a następnie można wykonać żądanie ściągnięcia. GitHub Flow jest również znany z obsługi ciągłego dostarczania (CD) w projekcie. Ponieważ zmiany wprowadzone w gałęzi głównej muszą zostać natychmiast wdrożone na serwerze.

Strategia GitFlow

Poprzednia strategia (GitHub Flow) nie była w zasadzie zbyt skomplikowana. Istnieją dwa typy gałęzi: gałęzie główne i gałęzie fabularne. Ale GitFlow jest poważniejszy. Przynajmniej możesz to zrozumieć z powyższego obrazka). Jak więc działa ta strategia? Ogólnie rzecz biorąc, GitFlow składa się z dwóch gałęzi stałych i kilku typów gałęzi tymczasowych (w kontekście GitHub Flow gałąź główna jest trwała, a pozostałe są tymczasowe). Oddziały stałe:

• mistrz: nikt nie powinien dotykać tej gałęzi ani niczego tam pchać. W tej strategii master wyświetla najnowszą stabilną wersję, która jest używana w produkcji (czyli na prawdziwym serwerze);
• rozwój jest gałęzią rozwoju. Potencjalnie może być niestabilny.

Rozwój odbywa się za pomocą trzech pomocniczych gałęzi tymczasowych :

1. Gałęzie funkcji - do opracowywania nowych funkcjonalności.
2. Wydaj gałęzie - aby przygotować się na wydanie nowej wersji projektu.
3. Gałęzie poprawek to szybkie rozwiązanie defektu, który został już znaleziony przez prawdziwych użytkowników na prawdziwym serwerze.

Gałęzie fabularne

Gałęzie funkcji są tworzone przez programistów dla nowych funkcjonalności. Powinny zawsze opierać się na gałęzi rozwojowej. Po zakończeniu prac nad nową funkcjonalnością należy utworzyć pull request w gałęzi deweloperskiej. Oczywiste jest, że w dużych zespołach może istnieć więcej niż jedna gałąź funkcji na raz. Jeszcze raz zwróć uwagę na obrazek znajdujący się na początku opisu strategii GitFlow.

Uwolnij gałęzie

Po przygotowaniu wymaganej liczby nowych funkcjonalności w branży deweloperskiej można przygotować się do wydania nowej wersji produktu. Pomoże nam w tym gałąź release. który jest tworzony w oparciu o gałąź deweloperską. Pracując z gałęzią wydania, musisz znaleźć i naprawić wszystkie defekty. Wszelkie nowe zmiany wymagane do ustabilizowania gałęzi wydania muszą zostać ponownie włączone do fazy rozwojowej. Ma to na celu stabilizację i rozwój branży. Kiedy testerzy stwierdzą, że gałąź jest wystarczająco stabilna, aby można było wypuścić nową wersję, zostaje ona scalona z gałęzią główną. Następnie na tym zatwierdzeniu tworzony jest tag (tag: więcej na ten temat możesz przeczytać tutaj ), któremu przypisywany jest numer wersji. Jako przykład możesz spojrzeć na obrazek na początku strategii. Zatem Tag 1.0 to po prostu etykieta wskazująca wersję 1.0 projektu. I ostatnią rzeczą jest poprawka gałęzi.

Gałęzie poprawek

Gałęzie poprawek są również przeznaczone do wydania nowej wersji w wersji master. Jedyną różnicą jest to, że to wydanie nie jest planowane. Zdarzają się sytuacje, gdy defekty docierają do wydania i są już wykryte na produkcji. Na przykład iOS: gdy tylko wypuszczą nową wersję, natychmiast otrzymasz kilka aktualizacji z poprawkami defektów wykrytych po wydaniu. W związku z tym konieczne jest szybkie naprawienie tej wady i wydanie nowej wersji. Na naszym zdjęciu odpowiada to wersji 1.0.1. Pomysł jest taki, że praca nad nową funkcjonalnością nie może kończyć się w momencie, gdy trzeba naprawić usterkę na prawdziwym serwerze (jak mówimy „w produkcji”: znowu kopia angielskiego słowa „produkcja”). Gałąź poprawki powinna zostać utworzona na podstawie gałęzi głównej, ponieważ reprezentuje ona stan, który działa w środowisku produkcyjnym. Gdy tylko rozwiązanie usterki będzie gotowe, zostaje ono scalone z wzorcem i tworzona jest nowa etykieta. Podobnie jak w przypadku przygotowywania gałęzi wydania, gałąź poprawek powinna scalić swoje rozwiązanie z gałęzią deweloperską.

Strategia rozwidlania przepływu pracy

W ramach strategii Forking Workflow rozwój odbywa się w taki sposób, że istnieją dwa repozytoria:

1. Oryginalne repozytorium, do którego zostaną scalone wszystkie zmiany.
2. Repozytorium fork (jest to kopia oryginalnego repozytorium będąca w posiadaniu innego programisty, który chce wprowadzić zmiany w oryginale).

Jak dotąd brzmi to trochę dziwnie, prawda? Dla tych, którzy już zetknęli się z rozwojem oprogramowania typu open source, to podejście jest już znajome. Strategia ta ma następującą zaletę: rozwój można przeprowadzić w repozytorium fork bez przyznawania praw do wspólnego rozwoju w repozytorium oryginalnym. Oczywiście właściciel oryginalnego repozytorium ma prawo odrzucić proponowane zmiany. Albo zgódź się i zabij ich. Jest to wygodne zarówno dla właściciela oryginalnego repozytorium, jak i programisty, który chce wziąć udział w tworzeniu jakiegoś produktu. Możesz na przykład zaproponować zmiany w jądrze Linuksa . Jeśli Linus uzna, że ​​mają one sens, zmiany zostaną wprowadzone (!!!).

Przykład przepływu pracy z rozwidleniem

Forking Flow jest używany w GitHubie, gdy istnieje biblioteka, której chcesz użyć. Posiada wadę uniemożliwiającą pełne wykorzystanie. Załóżmy, że wystarczająco zagłębiłeś się w problem i znasz rozwiązanie. Stosując strategię The Forking Workflow, możesz rozwiązać ten problem bez nadawania praw do pracy w oryginalnym repozytorium biblioteki. Aby rozpocząć, musisz wybrać repozytorium, na przykład rdzeń Spring Framework . Znajdź przycisk Fork w prawym górnym rogu i kliknij go: Zajmie to trochę czasu, po czym kopia tego oryginalnego repozytorium pojawi się w Twoim konto osobiste, co wskaże, że jest to fork: Następnie możesz normalnie pracować z tym repozytorium, dodać zmiany w gałęzi master, a gdy wszystko będzie gotowe, utworzyć żądanie ściągnięcia do oryginalnego repozytorium. Aby to zrobić, kliknij przycisk Nowe żądanie ściągnięcia :

Którą strategię wybrać

Git to elastyczne i potężne narzędzie, które pozwala pracować z wykorzystaniem szerokiej gamy procesów i strategii. Jednak im większy wybór, tym trudniej jest teraz zdecydować, którą strategię wybrać. Oczywiste jest, że nie ma jednej odpowiedzi pasującej do wszystkich. Wszystko zależy od sytuacji. Istnieje jednak kilka zaleceń, które mogą w tym pomóc:

1. Lepiej najpierw wybrać najprostszą strategię. Przejdź do bardziej złożonych strategii tylko wtedy, gdy jest to konieczne.
2. Rozważ strategie, które mają jak najmniej typów oddziałów deweloperskich.
3. Przyjrzyj się zaletom i wadom różnych strategii i zgodnie z projektem wybierz tę właściwą.

To wszystko, co chciałem ci powiedzieć o strategii rozgałęziania w git. Dziękuję za uwagę :) Subskrybuj moje konto na GitHubie , często zamieszczam tam swoje prace w różnych technologiach i narzędziach, które wykorzystuję w swojej pracy

Przydatne linki

• Przepływ GitHub: najlepszy sposób korzystania z Git i GitHub
• Żądania ściągnięcia w GitHubie lub Jak mogę wprowadzić zmiany w projekcie innej osoby
• GitHub: Informacje o żądaniach ściągnięcia
• Ciągła integracja, dostarczanie i zróżnicowane wdrażanie
• Podstawy Gita: praca z tagami
• Habr: Pomyślny model rozgałęziania dla Git