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

Wstęp

Git stał się de facto branżowym standardem dla systemów kontroli wersji w tworzeniu oprogramowania. Powinieneś najpierw przeczytać mój artykuł o tym, czym jest Git i jak zacząć. Czytałeś to? Świetnie, ruszamy! Czy ci się to podoba, czy nie, to narzędzie stworzone przez Linusa Tovaldsa nie przejdzie na emeryturę. Dlatego warto porozmawiać o tym, jak zespoły rozproszone współpracują z Git i jaką strategię rozgałęziania powinny w tym celu wybrać. To nie jest pytanie bez znaczenia. Podczas tworzenia nowego zespołu programistów, który wcześniej ze sobą nie współpracował, strategia rozgałęziania jest często jedną z pierwszych rzeczy do podjęcia. A niektórzy ludzie będą mieli pianę z ust, aby udowodnić, że jedna strategia jest lepsza od innej. Chcę więc przekazać wam kilka ogólnych informacji na ich temat.

Czy konieczne są strategie rozgałęzień?

Są wręcz niezbędne. Bardzo potrzebne. Bo jeśli zespół się w czymś nie zgadza, to każdy członek zespołu zrobi, co chce:

• pracuje w jakimkolwiek oddziale
• łączenie się w dowolne inne gałęzie
• usunięcie niektórych oddziałów
• tworzenie nowych
• więc każdy członek zespołu będzie działał w niezarządzanym przepływie.

Dlatego mamy trzy strategie do rozważenia poniżej. Chodźmy!

Przepływ GitHuba

Ta strategia rozgałęzień, co dziwne, jest preferowana na GitHub :) Zawiera zestaw reguł :

1. Kod w gałęzi głównej nie może zostać złamany. Powinien być gotowy do użycia w dowolnym momencie. Oznacza to, że nie wolno tam umieszczać 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łąź funkcji na podstawie gałęzi głównej i nadać jej sensowną nazwę. Zatwierdź swój kod lokalnie i regularnie przesyłaj zmiany do tej samej gałęzi w zdalnym repozytorium.
3. Otwórz pull request (o pull requestach możesz przeczytać tutaj ), gdy uznasz, że praca jest gotowa i może zostać włączona do gałęzi master (lub jeśli nie masz pewności, ale chcesz uzyskać informację zwrotną na temat wykonanej pracy).
4. Po zatwierdzeniu nowej funkcji w żądaniu ściągnięcia można ją scalić z gałęzią główną.
5. Gdy zmiany zostaną scalone z gałęzią główną, należy je natychmiast wdrożyć na serwerze.

Według GitHub Flow, zanim zaczniesz pracować nad czymś nowym, czy to poprawką, czy nową funkcjonalnością, musisz stworzyć nową gałąź opartą na masterze i nadać jej odpowiednią nazwę. Następnie rozpoczynają się prace nad wdrożeniem. Powinieneś stale przesyłać zatwierdzenia do zdalnego serwera o tej samej nazwie. Gdy dojdziesz do wniosku, że wszystko jest gotowe, musisz utworzyć pull request do gałęzi master. Następnie co najmniej jedna, a jeszcze lepiej dwie osoby powinny spojrzeć na ten kod przed kliknięciem „Zatwierdź”. Zwykle lider zespołu projektu i druga osoba zdecydowanie powinni rzucić okiem. Następnie możesz zakończyć żądanie ściągnięcia. GitHub Flow jest również znany z ciągłego dostarczania (CD) w projektach. Dzieje się tak dlatego, że gdy zmiany trafiają do gałęzi głównej, powinny zostać natychmiast wdrożone na serwerze.

GitFlow

Poprzednia strategia (GitHub Flow) nie jest w swej istocie bardzo skomplikowana. Istnieją dwa rodzaje gałęzi: główna i fabularna. Ale GitFlow jest poważniejszy. Przynajmniej powyższy obrazek powinien to wyjaśnić :) Jak więc działa ta strategia? Ogólnie rzecz biorąc, GitFlow składa się z dwóch trwałych gałęzi i kilku rodzajów tymczasowych gałęzi. W kontekście GitHub Flow gałąź master jest trwała, a pozostałe tymczasowe. Trwałe gałęzie

• mistrz: Nikt nie powinien niczego dotykać ani pchać do tej gałęzi. W tej strategii master reprezentuje najnowszą stabilną wersję, która jest używana w produkcji (czyli na prawdziwym serwerze)
• rozwój: Oddział deweloperski. Może być niestabilny.

Rozwój odbywa się za pomocą trzech pomocniczych oddziałów tymczasowych :

1. Gałęzie funkcji — do opracowywania nowych funkcjonalności.
2. Gałęzie wydania — do przygotowania do wydania nowej wersji projektu.
3. Gałęzie poprawek — do szybkiego naprawiania błędów znalezionych przez prawdziwych użytkowników na prawdziwym serwerze.

Gałęzie funkcji

Gałęzie funkcji są tworzone przez programistów dla nowych funkcji. Zawsze powinny być tworzone w oparciu o gałąź deweloperską. Po zakończeniu prac nad nową funkcjonalnością należy utworzyć pull request do gałęzi deweloperskiej. Oczywiście duże zespoły mogą mieć jednocześnie więcej niż jedną gałąź funkcji. Spójrz jeszcze raz na obrazek na początku opisu strategii GitFlow.

Uwolnij gałęzie

Gdy wymagany zestaw nowych funkcjonalności będzie gotowy w dziale developerskim, można przygotować się do wydania nowej wersji produktu. Pomoże nam w tym gałąź wydania, która jest tworzona na bazie gałęzi deweloperskiej. Podczas pracy z gałęzią wydania musisz znaleźć i naprawić wszystkie błędy. Wszelkie nowe zmiany, które są wymagane do ustabilizowania gałęzi wydawniczej, muszą również zostać ponownie włączone do gałęzi programistycznej. Odbywa się to również w celu ustabilizowania gałęzi deweloperskiej. Gdy testerzy stwierdzą, że gałąź jest wystarczająco stabilna do wydania nowego wydania, zostaje ona włączona do gałęzi głównej. Później dla tego zatwierdzenia tworzony jest znacznik, któremu jest przypisany numer wersji. Aby zobaczyć przykład, spójrz na obrazek na początku strategii. Tam zobaczysz Tag 1.0— to tylko znacznik wskazujący wersję 1.0 projektu. I wreszcie, mamy gałąź hotfix.

Gałęzie poprawek

Gałęzie poprawek są również przeznaczone do wydawania nowej wersji do gałęzi głównej. Jedyna różnica polega na tym, że te wydania nie są planowane. Zdarzają się sytuacje, kiedy błędy dostają się do wydanej wersji i są wykrywane w środowisku produkcyjnym. Weź iOS: gdy tylko zostanie wydana nowa wersja, natychmiast otrzymasz kilka aktualizacji z poprawkami błędów znalezionych po wydaniu. W związku z tym musimy szybko naprawić błąd i wydać nową wersję. Na naszym obrazie odpowiada to wersji 1.0.1. Chodzi o to, aby prace nad nową funkcjonalnością nie musiały się kończyć, gdy trzeba naprawić błąd na prawdziwym serwerze (lub jak to się mówi „w produkcji” lub „w produkcji”). Gałąź poprawki powinna zostać utworzona z gałęzi głównej, ponieważ reprezentuje to, co jest aktualnie uruchomione w środowisku produkcyjnym. Gdy tylko naprawienie błędu będzie gotowe, jest scalany z głównym i tworzony jest nowy znacznik. Podobnie jak przygotowanie gałęzi wydania, gałąź poprawki powinna również scalić swoją poprawkę z powrotem w gałąź deweloperską.

Rozwidlenie przepływu pracy

W przepływie pracy forking programowanie obejmuje dwa repozytoria:

1. Oryginalne repozytorium, do którego zostaną scalone wszystkie zmiany.
2. Repozytorium forków. To jest kopia oryginalnego repozytorium, której właścicielem jest inny programista, który chce wprowadzić zmiany w oryginale.

Jak dotąd brzmi to trochę dziwnie, prawda? Każdy, kto miał już styczność z programowaniem open source, zna to podejście. Ta strategia daje następującą zaletę: rozwój może odbywać się w repozytorium fork bez przyznawania uprawnień do wspólnego rozwoju w oryginalnej gałęzi. Oczywiście właściciel pierwotnego repozytorium ma prawo odrzucić proponowane zmiany. Lub zaakceptować i połączyć je. Jest to wygodne zarówno dla właściciela oryginalnego repozytorium, jak i programisty, który chce pomóc w tworzeniu produktu. Na przykład możesz zasugerować zmiany w jądrze Linuksa . Jeśli Linus uzna, że ​​mają sens, zmiany zostaną dodane (!!!).

Przykład przepływu pracy rozwidlenia

Przepływ pracy rozwidlenia jest stosowany w usłudze GitHub, gdy istnieje biblioteka, której chcesz użyć. Ma błąd, który uniemożliwia pełne korzystanie z niego. Załóżmy, że zagłębiłeś się w problem wystarczająco głęboko i znasz rozwiązanie. Korzystając z przepływu pracy forking, możesz rozwiązać problem bez uprawnień do pracy w oryginalnym repozytorium biblioteki. Aby rozpocząć, musisz wybrać jakieś repozytorium, na przykład Spring Framework . Znajdź i kliknij przycisk „Widelec” w prawym górnym rogu: To zajmie trochę czasu. Następnie na Twoim koncie osobistym pojawi się kopia oryginalnego repozytorium, co wskaże, że jest to fork:Teraz możesz normalnie pracować z tym repozytorium, dodając zmiany do gałęzi master, a gdy wszystko będzie gotowe, możesz utworzyć pull request 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. Ale im więcej masz możliwości wyboru, tym trudniej jest zdecydować, którą strategię wybrać. Wiadomo, że nie ma jednej odpowiedzi dla wszystkich. Wszystko zależy od sytuacji. To powiedziawszy, istnieje kilka wskazówek, które mogą w tym pomóc:

1. Najlepiej najpierw wybrać najprostszą strategię. Przechodź do bardziej złożonych strategii tylko wtedy, gdy jest to konieczne.
2. Rozważ strategie, które mają jak najmniej typów gałęzi dla programistów.
3. Przyjrzyj się zaletom i wadom różnych strategii, a następnie wybierz tę, której potrzebujesz do swojego projektu.

To wszystko, co chciałem powiedzieć o strategiach rozgałęziania w Git. Dziękuję za uwagę :) Śledź mnie na GitHubie , gdzie często wrzucam swoje prace z wykorzystaniem różnych technologii i narzędzi, których używam w swojej pracy.