Wyjaśnienie ulepszonego przepływu Git

Nieumyślne spowodowanie szkód za pomocą Git może być zbyt łatwe. Jednak najlepszy sposób korzystania z Gita zawsze będzie kontrowersyjny.

Dzieje się tak, ponieważ sam Git szczegółowo opisuje tylko podstawowe operacje rozgałęziania, co pozostawia wzorce użycia — tj. modele rozgałęzień — kwestią opinii użytkownika. Modele rozgałęziania Git obiecują złagodzić ból, organizując chaos, który nieuchronnie pojawia się, gdy programiści wprowadzają zmiany w swoich bazach kodu.

Podobnie jak wielu programistów, chciałeś czegoś, co „po prostu działa”, abyś mógł zająć się faktycznym tworzeniem oprogramowania. Więc wybrałeś Git flow , model rozgałęziania często polecany użytkownikom Git. Być może na początku byłeś na pokładzie z logiką Git flow, dopóki nie natrafiłeś na kilka problemów w praktyce. A może przepływ Git nie wydaje się wystarczająco dobry, abyś go zaadoptował. W końcu w grę wchodzą niezliczone zmienne i żaden pojedynczy model rozgałęzień nie sprawdzi się w każdej sytuacji.

Dobre wieści! Odmiana klasycznego modelu przepływu Git, ulepszony przepływ Git, upraszcza bardziej typowe manewry przepływu pracy Git, zachowując jednocześnie główne zalety.

Splendor i niedola klasycznego modelu przepływu Git

Jestem zagorzałym zwolennikiem Git flow, odkąd odkryłem, jak wyróżnia się on przy opracowywaniu produktu, który ewoluuje w znacznych przyrostach wartości (innymi słowy, wydaniach ).

Znaczący przyrost wartości wymaga znacznej ilości czasu do ukończenia, podobnie jak dwutygodniowe sprinty zwykle używane w programowaniu opartym na Scrumie. Jeśli zespół programistów wdrożył już w środowisku produkcyjnym, mogą pojawić się problemy, jeśli zakres następnego wydania kumuluje się w tym samym miejscu, w którym znajduje się kod produkcyjny — np. w głównej gałęzi repozytorium Git, z którego korzysta.

Chociaż produkt jest wciąż w początkowej fazie rozwoju — tj. nie ma produkcji i nie ma rzeczywistych użytkowników produktu — zespół może po prostu trzymać wszystko w głównej gałęzi. W rzeczywistości jest więcej niż w porządku: ta strategia pozwala na najszybsze tempo rozwoju bez większej ceremonii. Ale rzeczy się zmieniają w środowisku produkcyjnym; wtedy prawdziwi ludzie zaczynają polegać na tym, że produkt jest stabilny.

Na przykład, jeśli w środowisku produkcyjnym wystąpi krytyczny błąd, który wymaga natychmiastowej naprawy, poważną katastrofą dla zespołu programistów byłoby wycofanie całej dotychczasowej pracy nagromadzonej w głównej gałęzi tylko po to, aby wdrożyć poprawkę. Wdrażanie kodu bez odpowiedniego testowania — niezależnie od tego, czy jest on uważany za niedopracowany, czy dobrze opracowany — nie wchodzi w grę.

Właśnie tam błyszczą modele rozgałęzione, w tym przepływ Git. Każdy wyrafinowany model rozgałęziania powinien odpowiadać na pytania dotyczące tego, jak odizolować następne wydanie od wersji systemu aktualnie używanego przez ludzi, jak zaktualizować tę wersję do następnej wersji oraz jak wprowadzić poprawki wszelkich krytycznych błędów do bieżącej wersji.

Proces przepływu Git zajmuje się tymi podstawowymi scenariuszami, oddzielając gałęzie „main” (gałąź produkcyjna lub „bieżąca wersja”) i „develop” (gałąź deweloperska lub „następna wersja”) i zapewniając wszystkie zasady dotyczące korzystania z gałęzi funkcji/wydania/poprawek . Skutecznie rozwiązuje wiele problemów związanych z przepływami pracy przy opracowywaniu produktów opartych na wydaniu.

Ale nawet w przypadku projektów dobrze dopasowanych do klasycznego modelu przepływu Git, napotkałem typowe problemy, jakie może to spowodować:

• Przepływ Git jest złożony, z dwiema długowiecznymi gałęziami, trzema rodzajami gałęzi tymczasowych i ścisłymi regułami dotyczącymi wzajemnego oddziaływania gałęzi. Taka złożoność zwiększa prawdopodobieństwo błędów i zwiększa wysiłek potrzebny do ich naprawienia.
• Gałęzie wydania i poprawek wymagają „podwójnego łączenia” — raz w main, a potem w development. Czasami możesz zapomnieć o obu. Możesz ułatwić rozgałęzianie przepływu Git za pomocą skryptów lub wtyczek klienta VCS GUI, ale musisz je najpierw skonfigurować dla każdej maszyny każdego programisty zaangażowanego w dany projekt.
• W przepływach pracy CI/CD zwykle otrzymujesz dwie końcowe kompilacje dla wydania — jedną z ostatniego zatwierdzenia samej gałęzi wydania, a drugą z zatwierdzenia scalającego do głównego. Ściśle mówiąc, powinieneś użyć jednego z głównych, ale oba są zwykle identyczne, co stwarza potencjalne zamieszanie.

Wpisz „Ulepszony przepływ Git”

Po raz pierwszy użyłem ulepszonego przepływu Git w projekcie o zamkniętym kodzie źródłowym. Pracowałem z jeszcze jednym deweloperem i pracowaliśmy nad projektem bezpośrednio związując się z głównym oddziałem.

Uwaga: aż do pierwszego publicznego wydania produktu absolutnie sensowne jest wprowadzanie wszystkich zmian bezpośrednio do głównej gałęzi — nawet jeśli jesteś zwolennikiem przepływu Git — ze względu na szybkość i prostotę przepływu pracy deweloperskiej. Ponieważ nie ma jeszcze produkcji, nie ma możliwości wystąpienia błędu produkcyjnego, który zespół musi naprawić jak najszybciej. Wykonywanie całej magii rozgałęziania, którą pociąga za sobą klasyczny przepływ Git, jest zatem przesadą na tym etapie.

Potem zbliżyliśmy się do pierwszego wydania i zgodziliśmy się, że po tym punkcie nie będziemy już komfortowo angażować się bezpośrednio w główną gałąź. Poruszaliśmy się dość szybko, a priorytety biznesowe nie pozostawiały wiele miejsca na ustanowienie solidnego procesu rozwoju — tj. takiego, w którym zautomatyzowane testy dawałyby nam pewność, że nasza główna gałąź będzie w stanie gotowości do wydania.

Wydawało się, że to dobry przypadek dla klasycznego modelu przepływu Git. Przy oddzielnych gałęziach głównych i rozwojowych oraz wystarczającej ilości czasu między znaczącymi przyrostami wartości, istniało przekonanie, że w większości ręczna kontrola jakości przyniesie wystarczająco dobre wyniki. Kiedy opowiadałem się za Git flow, mój kolega zasugerował coś podobnego, ale z pewnymi kluczowymi różnicami.

Na początku odepchnąłem się. Wydawało mi się, że niektóre z proponowanych „łat” do klasycznego przepływu Git były nieco zbyt rewolucyjne. Pomyślałem, że mogą złamać główną ideę i całe podejście się nie powiedzie. Ale po zastanowieniu zdałem sobie sprawę, że te poprawki w rzeczywistości nie zakłócają przepływu Git. Tymczasem sprawiają, że jest to lepszy model rozgałęziania Git, rozwiązując wszystkie problemy wymienione powyżej.

Po sukcesie ze zmodyfikowanym podejściem w tym projekcie, użyłem go w innym projekcie o zamkniętym kodzie źródłowym z małym zespołem za nim, gdzie byłem stałym właścicielem bazy kodu i od czasu do czasu pomagałem zewnętrznym programistom. W tym projekcie weszliśmy do produkcji w sześć miesięcy i od tego czasu używamy testów CI i E2E przez ponad rok, z wydaniami mniej więcej co miesiąc.

Moje ogólne doświadczenie z tym nowym podejściem do gałęzi było tak pozytywne, że chciałem podzielić się nim z innymi programistami, aby pomóc im ominąć wady klasycznego przepływu Git.

Podobieństwa do klasycznego przepływu Git: izolacja rozwoju

Do izolacji pracy w ulepszonym przepływie Git nadal istnieją dwie długowieczne gałęzie, główna i rozwijana. (Użytkownicy nadal mają możliwości poprawek i wydań — z naciskiem na „zdolności”, ponieważ nie są to już gałęzie. Szczegóły omówimy w rozdziale dotyczącym różnic).

Nie ma oficjalnego schematu nazewnictwa gałęzi funkcji klasycznego przepływu Git. Po prostu odgałęziasz się od programowania i łączysz z powrotem, aby programować, gdy funkcja będzie gotowa. Zespoły mogą używać dowolnej konwencji nazewnictwa lub po prostu mieć nadzieję, że programiści będą używać bardziej opisowych nazw niż „moja gałąź”. To samo dotyczy ulepszonego przepływu Git.

Wszystkie funkcje zgromadzone w gałęzi deweloperskiej do pewnego punktu odcięcia będą kształtować nową wersję.

Squash łączy

Zdecydowanie zalecam używanie squash merge dla gałęzi funkcji, aby historia była ładna i liniowa przez większość czasu. Bez tego wykresy commitów (z narzędzi GUI lub git log --graph ) zaczynają wyglądać niechlujnie, gdy zespół żongluje nawet kilkoma gałęziami funkcji:

Ale nawet jeśli jesteś w porządku z wizualizacjami w tym scenariuszu, jest jeszcze jeden powód, by zmiażdżyć. Bez zgniatania, zatwierdzaj widoki historii — wśród nich zarówno zwykły git log (bez --graph ), jak i GitHub — opowiadaj raczej niespójne historie nawet w najprostszych scenariuszach scalania:

Zastrzeżeniem związanym z używaniem squasha jest to, że oryginalna historia gałęzi funkcji zostaje utracona. Ale to zastrzeżenie nie ma nawet zastosowania, jeśli na przykład korzystasz z usługi GitHub, która ujawnia pełną oryginalną historię gałęzi funkcji za pomocą żądania ściągnięcia, które zostało scalone metodą squasha, nawet po usunięciu samej gałęzi funkcji.

Różnice w stosunku do klasycznego Git Flow: wydania i poprawki

Przejdźmy przez cykl wydań, ponieważ (miejmy nadzieję) jest to najważniejsza rzecz, którą będziesz robić. Kiedy dochodzimy do punktu, w którym chcielibyśmy uwolnić to, co nagromadziło się w rozwoju, jest to ściśle superzbiór głównych. Od tego momentu zaczynają się największe różnice między klasycznym a ulepszonym przepływem Git.

Wydania w ulepszonym przepływie Git

Każdy etap tworzenia wersji z ulepszonym przepływem Git różni się od klasycznego procesu przepływu Git:

1. Wydania oparte są na głównym, a nie rozwijanym. Oznacz bieżącą końcówkę głównej gałęzi czymś znaczącym. Przyjąłem tagi oparte na bieżącej dacie w formacie ISO 8601 z przedrostkiem „v” — np. v2020-09-09 .
   • Jeśli zdarzyło się, że w ciągu jednego dnia wydano wiele wydań — na przykład poprawki — do formatu można było w razie potrzeby dołączyć kolejny numer lub literę.
   • Należy pamiętać, że tagi generalnie nie odpowiadają datom wydania. Mają one na celu wyłącznie zmuszenie Gita do zachowania odniesienia do tego, jak wyglądała główna gałąź w momencie rozpoczęcia kolejnego procesu wydawania.
2. Wypchnij tag za pomocą git push origin <the new tag name> .
3. Potem mała niespodzianka: usuń swój lokalny oddział główny . Nie martw się, ponieważ wkrótce go przywrócimy.
   • Wszystkie zatwierdzenia do main są nadal bezpieczne — zabezpieczyliśmy je przed wyrzucaniem śmieci, oznaczając main w poprzednim kroku. Każde z tych zatwierdzeń — nawet poprawki, o czym niedługo omówimy — jest również częścią developmentu.
   • Tylko upewnij się, że tylko jedna osoba w zespole robi to dla danego wydania; to jest tak zwana rola „menedżera wydań”. Menedżer ds. wydania jest zwykle najbardziej doświadczonym i/lub najstarszym członkiem zespołu, ale zespół powinien unikać stałego pełnienia tej roli przez żadnego konkretnego członka zespołu. Bardziej sensowne jest rozpowszechnianie wiedzy w zespole, aby zwiększyć niesławny czynnik autobusowy.
4. Utwórz nową lokalną gałąź główną w momencie zatwierdzenia napiwku swojej gałęzi deweloperskiej .
5. Wypchnij tę nową strukturę za pomocą git push --force , ponieważ zdalne repozytorium nie zaakceptuje tak łatwo tak „drastycznej zmiany”. Ponownie, nie jest to tak niebezpieczne, jak mogłoby się wydawać w tym kontekście, ponieważ:
   • Po prostu przenosimy wskaźnik głównej gałęzi z jednego zatwierdzenia do drugiego.
   • Tylko jeden konkretny członek zespołu wprowadza tę zmianę naraz.
   • Codzienna praca programistyczna odbywa się na gałęzi deweloperskiej, więc nie zakłócisz nikomu pracy, przenosząc main w ten sposób.
6. Masz swoje nowe wydanie! Wdróż go w środowisku testowym i przetestuj. (Poniżej omówimy wygodne wzorce CI/CD.) Wszelkie poprawki trafiają bezpośrednio do gałęzi głównej i z tego powodu zaczną odbiegać od gałęzi deweloperskiej.
   • W tym samym czasie możesz rozpocząć pracę nad nowym wydaniem w gałęzi deweloperskiej, ta sama zaleta, którą widać w klasycznym przepływie Git.
   • W niefortunnym przypadku, gdy poprawka jest potrzebna do tego, co jest obecnie w produkcji (a nie nadchodzącej wersji w fazie testowej), więcej szczegółów na temat tego scenariusza można znaleźć w sekcji „Postępowanie z poprawkami podczas aktywnego wydania…” poniżej.
7. Gdy nowa wersja zostanie uznana za wystarczająco stabilną, wdróż ostateczną wersję w środowisku produkcyjnym i wykonaj pojedyncze scalanie squash z głównym, aby opracować wszystkie poprawki.

Poprawki w ulepszonym przepływie Git

Przypadki poprawek są dwojakie. Jeśli robisz poprawkę , gdy nie ma aktywnej wersji — tj. zespół przygotowuje nową wersję w gałęzi deweloperskiej — jest to bardzo proste: zdecyduj się na główne, wdróż swoje zmiany i przetestuj je na etapie, aż będą gotowe, a następnie wdrożyć do produkcji.

W ostatnim kroku wybierz swój commit z main do opracowania, aby mieć pewność, że następne wydanie będzie zawierało wszystkie poprawki. Jeśli skończysz z kilkoma zatwierdzeniami poprawek, oszczędzasz wysiłek — zwłaszcza jeśli Twoje IDE lub inne narzędzie Git może to ułatwić — tworząc i stosując łatkę zamiast wielokrotnego wybierania wisienek. Próba squash merge main by developer po pierwszym wydaniu może skończyć się konfliktami z niezależnymi postępami dokonanymi w gałęzi developerskiej, więc nie polecam tego.

Radzenie sobie z poprawkami podczas aktywnego wydania — to znaczy, gdy po prostu naciskasz na main i wciąż przygotowujesz nowe wydanie — jest najsłabszą częścią ulepszonego przepływu Git. W zależności od długości cyklu wydawniczego i wagi problemu, który musisz rozwiązać, zawsze staraj się uwzględniać poprawki w samej nowej wersji — jest to najłatwiejszy sposób i nie zakłóca w ogóle ogólnego przepływu pracy.

Jeśli nie możesz tego zrobić — musisz szybko wprowadzić poprawkę i nie możesz się doczekać, aż nowa wersja będzie gotowa — przygotuj się na nieco skomplikowaną procedurę Git:

1. Utwórz gałąź — nazwiemy ją „nową wersją”, ale Twój zespół może tutaj przyjąć dowolną konwencję nazewnictwa — w tym samym zatwierdzeniu, co aktualna wskazówka dotycząca main. Wypchnij nowe wydanie.
2. Usuń i ponownie utwórz lokalną gałąź główną przy zatwierdzeniu znacznika utworzonego wcześniej dla bieżącego aktywnego wydania. Siła pchania głównego.
3. Wprowadź niezbędne poprawki do głównego, wdróż w środowisku pomostowym i przetestuj. Gdy wszystko będzie gotowe, wdróż w środowisku produkcyjnym.
4. Rozpowszechniaj zmiany z bieżącej wersji głównej do nowej wersji za pomocą wyselekcjonowania lub łatki.
5. Następnie wykonaj ponownie procedurę zwalniania: Oznacz końcówkę bieżącej wersji głównej i wciśnij tag, usuń i ponownie utwórz lokalną sieć główną na końcu gałęzi nowego wydania i wymuś push main.
   1. Prawdopodobnie nie będziesz potrzebować poprzedniego tagu, więc możesz go usunąć.
   2. Gałąź nowej wersji jest teraz zbędna, więc możesz ją również usunąć.
6. Teraz powinieneś być gotowy, aby przejść jak zwykle z nowym wydaniem. Na koniec rozpropaguj awaryjne poprawki od strony głównej do deweloperskiej poprzez wybieranie wisienek lub łatkę.

Przy odpowiednim planowaniu, wystarczająco wysokiej jakości kodu oraz zdrowej kulturze programowania i zapewniania jakości jest mało prawdopodobne, aby Twój zespół musiał korzystać z tej metody. Rozsądnie było opracować i przetestować taki plan awaryjny dla ulepszonego przepływu Git, na wszelki wypadek — ale nigdy nie musiałem go używać w praktyce.

Konfiguracja CI/CD na szczycie ulepszonego przepływu Git

Nie każdy projekt wymaga dedykowanego środowiska programistycznego. Skonfigurowanie zaawansowanego lokalnego środowiska programistycznego na każdym komputerze deweloperskim może być dość łatwe.

Ale dedykowane środowisko programistyczne może przyczynić się do zdrowszej kultury rozwoju. Przeprowadzanie testów, mierzenie pokrycia testami i obliczanie metryk złożoności w gałęzi deweloperskiej często zmniejsza koszt błędów, wyłapując je na długo, zanim dotrą do etapu.

Odkryłem, że niektóre wzorce CI/CD są szczególnie przydatne w połączeniu z ulepszonym przepływem Git:

• Jeśli potrzebujesz środowiska programistycznego, skonfiguruj CI, aby kompilować, testować i wdrażać w nim po każdym zatwierdzeniu w gałęzi programistycznej. Dopasuj się do testów E2E również tutaj, jeśli je masz i jeśli ma to sens w twoim przypadku.
• Skonfiguruj CI, aby kompilować, testować i wdrażać w środowisku przejściowym przy każdym zatwierdzeniu w głównej gałęzi. Testowanie E2E jest również bardzo korzystne w tym momencie.
  • Używanie testów E2E w obu miejscach może wydawać się zbędne, ale pamiętaj, że poprawki nie pojawią się w fazie rozwoju. Wyzwalanie E2E przy zatwierdzeniu do głównego przetestuje poprawki i codzienne zmiany, zanim wyjdą, ale również wyzwolenie przy zatwierdzeniu do opracowania wykryje błędy wcześniej.
• Skonfiguruj CI w sposób, który pozwoli Twojemu zespołowi na wdrażanie kompilacji ze środowiska głównego do produkcyjnego na żądanie ręczne.

Takie wzorce są stosunkowo proste, ale zapewniają potężną maszynerię do wspierania codziennych operacji rozwojowych.

Ulepszony model przepływu Git: ulepszenia i możliwe ograniczenia

Ulepszony przepływ Git nie jest dla wszystkich. Wykorzystuje kontrowersyjną taktykę siły popychającej główną gałąź, więc puryści mogą się do niej odrazić. Jednak z praktycznego punktu widzenia nie ma w tym nic złego.

Jak wspomniano, poprawki są trudniejsze podczas wydania, ale nadal są możliwe. Przy odpowiedniej dbałości o zapewnienie jakości, pokrycie testów itp. nie powinno to zdarzać się zbyt często, więc z mojej perspektywy jest to ważny kompromis dla ogólnych korzyści płynących z ulepszonego przepływu Git w porównaniu z klasycznym przepływem Git. Byłbym bardzo zainteresowany, aby usłyszeć, jak ulepszony przepływ Git wypada w większych zespołach i przy bardziej złożonych projektach, w których poprawki mogą występować częściej.

Moje pozytywne doświadczenia z ulepszonym modelem przepływu Git dotyczą również projektów komercyjnych o zamkniętym kodzie źródłowym. Może to być problematyczne w przypadku projektu typu open source, w którym żądania ściągnięcia są często oparte na wyprowadzeniu starego wydania drzewa źródłowego. Nie ma technicznych przeszkód, aby to rozwiązać — może to wymagać więcej wysiłku niż oczekiwano. Z zadowoleniem przyjmuję opinie czytelników z dużym doświadczeniem w przestrzeni open source dotyczące możliwości zastosowania ulepszonego przepływu Git w takich przypadkach.

Specjalne podziękowania dla kolegi Toptal, Antoine'a Phama, za jego kluczową rolę w rozwijaniu idei ulepszonego przepływu Git.

Dalsza lektura na blogu Toptal Engineering:

• Programowanie oparte na trunku a Git Flow
• Przepływy pracy Git dla profesjonalistów: dobry przewodnik po Git

Jako Złoty Partner Microsoft, Toptal jest Twoją elitarną siecią ekspertów Microsoft. Twórz wysoko wydajne zespoły z ekspertami, których potrzebujesz - w dowolnym miejscu i dokładnie wtedy, gdy ich potrzebujesz!