Przepływ pracy gałęzi funkcji w systemie Git
Podstawowym założeniem przepływu pracy gałęzi funkcji jest to, że cały proces opracowywania funkcji powinien się odbywać w obrębie gałęzi dedykowanej, a nie main. Taka enkapsulacja ułatwia wielu programistom pracę nad określoną funkcją bez zakłócania głównej bazy kodu. Oznacza to również, że gałąź main nigdy nie będzie zawierała uszkodzonego kodu, co jest ogromną zaletą w środowiskach ciągłej integracji.
Hermetyzacja opracowywania funkcji pozwala również na użycie pull requestów, które stanowią jeden ze sposobów na zainicjowanie dyskusji na temat gałęzi. Dają one pozostałym programistom możliwość zaakceptowania funkcji przed jej zintegrowaniem z oficjalnym projektem. Natomiast w przypadku utknięcia przy opracowywaniu funkcji można otworzyć pull request z prośbą o sugestie od współpracowników. Pull requesty niezwykle ułatwiają zespołowi wzajemne komentowanie efektów pracy.
Przepływ pracy gałęzi funkcji to elastyczne rozwiązanie, które może być wykorzystywane przez inne przepływy pracy wysokiego poziomu w systemie Git. Pozostałe rodzaje przepływów pracy występujące w systemie Git omówiliśmy tutaj. Przepływ pracy gałęzi funkcji w systemie Git koncentruje się na modelu rozgałęziania, co oznacza, że stanowi strukturę do zarządzania i tworzenia gałęzi. Inne przepływy pracy w większym stopniu opierają się na repozytoriach. Przepływ pracy gałęzi funkcji w systemie Git można włączyć do innych przepływów. Przepływy pracy Gitflow i Git Forking zazwyczaj wykorzystują przepływ pracy gałęzi funkcji Git w zakresie modeli rozgałęziania.
Jak to działa
Przepływ pracy gałęzi funkcji zakłada korzystanie z centralnego repozytorium, a gałąź main pełni rolę oficjalnej historii projektu. Zamiast zatwierdzać bezpośrednio w lokalnej gałęzi main, programiści tworzą nową gałąź za każdym razem, gdy rozpoczynają pracę nad nową funkcją. Gałęzie funkcji powinny mieć opisowe nazwy, np. animowane-elementy-menu czy problem-#1061. Chodzi o to, by krótko i klarownie przekazać cel gałęzi. W Git nie ma technicznego rozróżnienia między gałęzią main a gałęziami funkcji, dzięki czemu programiści mogą edytować zmiany w gałęzi funkcji, a także przenosić je do przechowalni i zatwierdzać.
Ponadto gałęzie funkcji mogą (i powinny) zostać wypchnięte do centralnego repozytorium. Umożliwia to udostępnienie funkcji innym programistom bez ingerencji w oficjalny kod. Ponieważ main jest jedyną „specjalną” gałęzią, przechowywanie kilku gałęzi funkcji w centralnym repozytorium nie stwarza problemów. Oczywiście to również wygodny sposób na utworzenie kopii zapasowej wszystkich lokalnych commitów. Poniżej przedstawiamy opis cyklu życia gałęzi funkcji.
Zacznijmy od gałęzi głównej
Wszystkie gałęzie funkcji są tworzone z uwzględnieniem najnowszego stanu kodu projektu. W przewodniku założono, że jest on utrzymywany i aktualizowany w gałęzi main.
materiały pokrewne
Zaawansowany dziennik Git
POZNAJ ROZWIĄZANIE
Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud
git checkout main
git fetch origin
git reset --hard origin/mainUtwórz repozytorium
Powoduje to przełączenie repozytorium na gałąź main, wypchnięcie najnowszych commitów i zresetowanie lokalnej kopii gałęzi main w repozytorium, by była zgodna z najnowszą wersją.
Tworzenie nowej gałęzi
Użyj oddzielnej gałęzi dla każdej funkcji lub problemu, nad którym pracujesz. Po utworzeniu gałęzi wyewidencjonuj ją lokalnie, aby wszelkie wprowadzone zmiany znajdowały się w tej gałęzi.
git checkout -b new-featureTo polecenie wyewidencjonowuje gałąź o nazwie new-feature odchodzącą z gałęzi main, a flaga -b nakazuje utworzenie w systemie Git gałęzi, jeśli jeszcze ona nie istnieje.
Aktualizacja, dodawanie, zatwierdzanie i wypychanie zmian
W ramach tej gałęzi możesz edytować, przenosić do przechowalni i zatwierdzać zmiany w standardowy sposób, wykorzystując tyle commitów, ile to konieczne. Pracuj nad funkcją i dokonuj zatwierdzeń tak jak zazwyczaj, gdy używasz Git. Gdy nadejdzie właściwy moment, wypchnij commity, aktualizując gałąź funkcji w Bitbucket.
git status
git add <some-file>
git commitWypychanie gałęzi funkcji do zdalnego repozytorium
Dobrym pomysłem jest wypchnięcie gałęzi funkcji wyżej do centralnego repozytorium. To wygodny sposób na utworzenie kopii zapasowej, która w przypadku współpracy z innymi programistami daje im wgląd do commitów w nowej gałęzi.
git push -u origin new-featureTo polecenie wypycha nową funkcję do centralnego repozytorium (origin), zaś flaga -u powoduje dodanie jej jako zdalnej gałęzi śledzenia. Po skonfigurowaniu gałęzi śledzenia można wywołać polecenie git push bez parametrów, aby automatycznie wypchnąć gałąź nowej funkcji do centralnego repozytorium. Aby uzyskać informacje zwrotne na temat nowej gałęzi funkcji, utwórz pull request w narzędziu do zarządzania repozytorium, takim jak Bitbucket Cloud czy Bitbucket Data Center. Za jego pośrednictwem możesz dodawać recenzentów i upewnić się, że wszystko jest w porządku przed scaleniem.
Zastosowanie uwag zwrotnych
Teraz współpracownicy komentują i aprobują wypchnięte commity. Stosuj się do ich komentarzy lokalnie, zatwierdzaj i wypychaj sugerowane zmiany do Bitbucket. Twoje aktualizacje pojawiają się w pull requeście.
Scalanie pull requestu
Przed scaleniem może być konieczne rozwiązanie konfliktów scalania w wypadku, gdyby inne osoby wprowadziły zmiany w repozytorium. Gdy pull request zostanie zatwierdzony i będzie wolny od konfliktów, możesz dodać swój kod do gałęzi main. Scal na podstawie pull request w Bitbucket.
Polecenia pull request
Oprócz izolacji procesu programowania funkcji gałęzie umożliwiają omawianie zmian za pomocą pull requestów. Gdy użytkownik kończy opracowywanie funkcji, nie scala jej natychmiast z gałęzią main. Zamiast tego wypycha gałąź funkcji na serwer centralny i składa pull request z prośbą o scalenie zmian z gałęzią main. Daje to innym programistom możliwość oceny zmian, zanim staną się one częścią głównej bazy kodu.
Przegląd kodu jest główną zaletą pull requestów, ale przede wszystkim zostały one przewidziane jako metoda omawiania kodu. Pull requesty można postrzegać jako nośnik dyskusji nad poszczególnymi gałęziami. Oznacza to, że można je również wykorzystać znacznie wcześniej w procesie programowania. Gdy programista potrzebuje pomocy w zakresie określonej funkcji, może po prostu złożyć pull request. Zainteresowane osoby zostaną automatycznie powiadomione i oprócz pytania otrzymają od razu podgląd powiązanych commitów.
Po zaakceptowaniu pull requestu faktyczna procedura publikacji funkcji wygląda tak samo jak w przypadku scentralizowanego przepływu pracy. Najpierw należy się upewnić, że lokalna gałąź main jest zsynchronizowana z nadrzędną gałęzią main. Następnie gałąź funkcji scala się z gałęzią main, po czym zaktualizowaną gałąź main przesuwa się z powrotem do centralnego repozytorium.
Obsługa pull requestów jest łatwiejsza, gdy zastosuje się rozwiązania do zarządzania kodem źródłowym, takie jak Bitbucket Cloud.
Przykład
Poniżej przedstawiamy przykładowy scenariusz, w którym wykorzystywany jest przepływ pracy gałęzi funkcji. Zespół dokonuje przeglądu kodu nowej funkcji w odpowiedzi na pull request. To przykład jednego z wielu zastosowań tego modelu.
Mary tworzy nową funkcję
Przed rozpoczęciem opracowywania funkcji Mary potrzebuje odizolowanej gałęzi, na której będzie mogła pracować. Może zażądać utworzenia nowej gałęzi za pomocą następującego polecenia:
git checkout -b marys-feature mainTo pozwala wyewidencjonować gałąź o nazwie marys-feature odchodzącą z gałęzi main, a flaga -b nakazuje utworzenie gałęzi, jeśli jeszcze ona nie istnieje. W ramach tej gałęzi Mary może edytować, przenosić do przechowalni i zatwierdzać zmiany w standardowy sposób, wykorzystując tyle commitów, ile to konieczne:
git status
git add <some-file>
git commitMary wychodzi na obiad
.svg?cdnVersion=2441)
Mary dodaje do funkcji kilka commitów utworzonych przed przerwą obiadową. Przed wyjściem na lunch powinna wypchnąć gałęzie funkcji wyżej do centralnego repozytorium. To stanowi wygodną formę kopii zapasowej, zaś podczas współpracy z innymi programistami daje im wgląd do jej wcześniejszych commitów.
git push -u origin marys-featureTo polecenie wypycha marys-feature do centralnego repozytorium (origin), zaś flaga -u powoduje dodanie jej jako zdalnej gałęzi śledzenia. Po skonfigurowaniu gałęzi śledzenia Mary może wywołać git push bez parametrów, aby wypchnąć funkcję.
Mary kończy opracowywanie funkcji
Po powrocie z lunchu Mary dopracowuje funkcję. Przed scaleniem z gałęzią main musi złożyć pull request, aby poinformować resztę zespołu, że skończyła zadanie. Najpierw powinna się jednak upewnić, że jej ostatnie commity dotarły do centralnego repozytorium:
git pushNastępnie składa pull request za pomocą interfejsu systemu Git, prosząc o scalenie gałęzi marys-feature z gałęzią main, o czym członkowie zespołu zostają automatycznie powiadomieni. Świetną cechą pull requestów jest to, że komentarze wyświetlane są tuż obok powiązanych z nimi commitów, co ułatwia zadawanie pytań dotyczących konkretnych zmian.
Bill otrzymuje pull request
.svg?cdnVersion=2441)
Bill otrzymuje pull request i przegląda gałąź marys-feature. Stwierdza, że chce wprowadzić kilka zmian przed włączeniem funkcji do oficjalnego projektu, a także omawia pomysły z Mary za pomocą pull requestu.
Mary dokonuje zmian
.svg?cdnVersion=2441)
Do wprowadzenia zmian Mary stosuje dokładnie tę samą procedurę, za pomocą której powstała pierwsza iteracja jej funkcji. Edytuje, przenosi do przechowalni, zatwierdza i wypycha aktualizacje do centralnego repozytorium. Cała jej aktywność jest raportowana w pull requeście, a Bill może nadal na bieżąco przesyłać komentarze.
Może również pobrać funkcję marys-feature do swojego lokalnego repozytorium i samemu nad nią popracować. Dodane przez niego commity również pojawiłyby się w pull requeście.
Mary publikuje funkcję
Gdy Bill jest już gotów zaaprobować pull request, ktoś musi scalić funkcję ze stabilną wersją projektu (może to zrobić zarówno Bill, jak i Mary):
git checkout main
git pull
git pull origin marys-feature
git pushEfektem tego procesu jest często commit scalenia. Niektórzy programiści lubią to rozwiązanie, ponieważ stanowi symboliczne połączenie funkcji z resztą bazy kodu. Jeśli jednak wolisz zostać przy liniowej historii, przed wykonaniem scalenia możesz zmienić bazę funkcji na końcówkę gałęzi main, co będzie skutkować scaleniem z przewijaniem.
Niektóre interfejsy użytkownika automatyzują proces akceptowania pull requestów, umożliwiając uruchomienie wszystkich tych poleceń przez kliknięcie przycisku „Akceptuj”. Jeśli nie masz takiej opcji, interfejs powinien przynajmniej automatycznie zamknąć pull request, gdy gałąź funkcji zostanie scalona z main.
W międzyczasie John robi dokładnie to samo.
Podczas gdy Mary i Bill pracują nad gałęzią marys-feature i omawiają zmiany w pull requeście, John robi dokładnie to samo z własną gałęzią funkcji. Dzięki wyodrębnieniu funkcji w osobnych gałęziach każdy może pracować niezależnie, ale w razie potrzeby nadal można się dzielić zmianami z innymi programistami wtedy, gdy jest to potrzebne.
Podsumowanie
W tym dokumencie omówiliśmy przepływ pracy gałęzi funkcji. Ta forma przepływu pracy pomaga organizować i śledzić gałęzie, które są skoncentrowane na zestawach funkcji komercyjnych. Inne przepływy pracy systemu Git, takie jak Git Forking i Gitflow, są ukierunkowane na repozytoria i mogą wykorzystywać przepływ pracy gałęzi funkcji do zarządzania modelami rozgałęziania. Przedstawiliśmy przykład kodu wysokiego poziomu oraz fikcyjny przykład wdrożenia przepływu pracy gałęzi funkcji. Do kluczowych aspektów przepływu pracy gałęzi funkcji zaliczymy:
- skoncentrowanie na wzorach rozgałęziania,
- możliwość wykorzystania przez inne przepływy pracy ukierunkowane na repozytoria,
- promowanie współpracy z członkami zespołu za pośrednictwem pull requestów i przeglądów scalania.
Korzystanie z polecenia git rebase podczas etapów przeglądu i scalania gałęzi funkcji pozwala utworzyć spójną historię scaleń funkcji. Model rozgałęziania ułatwia promowanie współpracy w środowisku zespołowym.
Jeśli chcesz dowiedzieć się więcej o przepływach pracy systemu Git, przeczytaj nasz kompleksowy samouczek „Przepływ pracy Gitflow”.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Blog Bitbucket
Ścieżka szkoleniowa DevOps
