Adopt a Git branching strategy (Stosowanie strategii rozgałęziania systemu Git)

Azure Repos | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2015

Rozproszone systemy kontroli wersji, takie jak Git, zapewniają elastyczność korzystania z kontroli wersji do udostępniania kodu i zarządzania nimi. Twój zespół powinien znaleźć równowagę między tą elastycznością a potrzebą spójnej współpracy i udostępniania kodu.

Członkowie zespołu publikują, publikują, przeglądają i iterują po zmianach kodu za pośrednictwem gałęzi Git udostępnionych innym osobom. Przyjęcie strategii rozgałęzienia dla zespołu. Możesz współpracować lepiej i poświęcać mniej czasu na zarządzanie kontrolą wersji, a więcej na opracowywanie kodu.

Poniższe strategie rozgałęzień są oparte na witrynie Microsoft, w jaki sposób korzystamy z usługi Git. Aby uzyskać więcej informacji, zobacz Jak korzystać z usługi Git w firmie Microsoft.

Zachowaj prostą strategię gałęzi

Zachowaj prostą strategię gałęzi. Sbuduj strategię na tych trzech pojęciach:

  • Używaj gałęzi funkcji dla wszystkich nowych funkcji i poprawek błędów.
  • Scal gałęzie funkcji z główną gałęzią przy użyciu żądań ściągnięć.
  • Zachowaj wysoką jakość i aktualne gałęzie główne.

Strategia, która rozszerza te koncepcje i pozwala uniknąć konfliktów, spowoduje, że zespół będzie mieć spójny i łatwy w obsłudze przepływ pracy kontroli wersji.

Używanie gałęzi funkcji w swojej pracy

Opracowywanie funkcji i naprawianie usterek w gałęziach funkcji na podstawie gałęzi głównej. Te gałęzie są również nazywane gałęziami tematu. Gałęzie funkcji izolują prace w toku od ukończonych prac w gałęzi main. Gałęzie Git są niedrogie w tworzeniu i konserwacji. Nawet niewielkie poprawki i zmiany powinny mieć własną gałąź funkcji.

image of basic branching workflow

Tworzenie gałęzi funkcji dla wszystkich zmian sprawia, że przeglądanie historii jest proste. Przyjrzyj się zatwierdzeń wykonanym w gałęzi i przyjrzyj się żądaniu ściągnięciem, które scaliło gałąź.

Nazwij gałęzie funkcji według konwencji

Użyj spójnej konwencji nazewnictwa dla gałęzi funkcji, aby zidentyfikować pracę w gałęzi . W nazwie gałęzi można również uwzględnić inne informacje, takie jak osoba, która utworzyła gałąź.

Kilka sugestii dotyczących nazewnictwa gałęzi funkcji:

  • użytkownicy/nazwa użytkownika/opis
  • users/username/workitem
  • Poprawka usterek/opis
  • feature/nazwa-funkcji
  • feature/feature-area/feature-name
  • poprawka/opis

Uwaga

Aby uzyskać informacje na temat ustawiania zasad w celu wymuszenia strategii nazewnictwa gałęzi, zobacz Require branch folders (Wymaganie folderów gałęzi).

Używanie flag funkcji do zarządzania długotrwałych gałęziami

Dowiedz się więcej o używaniu flag funkcji w kodzie.

Przeglądanie i scalanie kodu z żądaniami ściągnięć

Przegląd, który odbywa się w żądaniu ściągnięcie, ma kluczowe znaczenie dla poprawy jakości kodu. Scalaj tylko gałęzie za pośrednictwem żądań ściągnięć, które przechodzą proces przeglądu. Unikaj scalania gałęzi z główną gałęzią bez żądania ściągnnięcia.

Przeglądy w żądaniach ściągnięć mogą zająć trochę czasu. Twój zespół powinien wyrazić zgodę na to, czego mogą oczekiwać od twórców i recenzentów żądania ściągnnięcia. Podziel się obowiązkami recenzentów, aby dzielić się pomysłami między swoimi zespołami i rozpowszechniać wiedzę na temat bazy kodu.

Sugestie dotyczące pomyślnych żądań ściągnięć:

  • Dwaj recenzentzy to optymalna liczba na podstawie badań.
  • Jeśli Twój zespół ma już proces przeglądu kodu, przekieruj żądania ściągnięć do tego, co już robisz.
  • Należy zadbać o przypisanie tych samych recenzentów do dużej liczby żądań ściągnięć. Żądania ściągnięć działają lepiej, gdy obowiązki recenzenta są współdzielone przez zespół.
  • Podaj wystarczająco dużo szczegółów w opisie, aby szybko wprowadzić zmiany w recenzentach.
  • Dołącz do żądania ściągnięcie kompilację lub powiązaną wersję zmian uruchomionych w środowisku etapowym. Inne osoby mogą łatwo przetestować zmiany.

Zachowanie wysokiej jakości, aktualnej gałęzi głównej

Kod w gałęzi głównej powinien przechodzić testy, kompilować w sposób czysty i zawsze być aktualny. Gałąź główna wymaga tych cech, aby gałęzie funkcji utworzone przez zespół rozpoczynały się od znanej dobrej wersji kodu.

Skonfiguruj zasady gałęzi dla gałęzi głównej, które:

  • Wymaga żądania ściągnnięcia w celu scalenia kodu. Takie podejście zapobiega bezpośrednim wypchnięciom do gałęzi main i zapewnia omówienie proponowanych zmian.
  • Automatycznie dodaje recenzentów po utworzeniu żądania ściągnnięcia. Dodani członkowie zespołu zapoznają się z kodem i komentują zmiany w żądaniu ściągnięcie.
  • Wymaga pomyślnej kompilacji do ukończenia żądania ściągnnięcia. Kod scalony z główną gałęzią powinien być kompilowany w sposób czysty.

Porada

Potok kompilacji dla żądań ściągnięć powinien być szybki do ukończenia, aby nie zakłócał procesu przeglądu.

Zarządzanie wydaniami

Używaj gałęzi wydań do koordynowania i ustabilizowania zmian w wydaniu kodu. Ta gałąź jest długotrwała i nie jest scalona z powrotem z główną gałęzią w żądaniu ściągnięcie, w przeciwieństwie do gałęzi funkcji. Utwórz tyle gałęzi wydań, ile potrzebujesz. Należy pamiętać, że każda aktywna gałąź wydania reprezentuje inną wersję kodu, który należy obsługiwać. Zablokuj gałęzie wydań, gdy wszystko będzie gotowe do zatrzymania obsługi określonej wersji.

Używanie gałęzi wydań

Utwórz gałąź wydania z gałęzi main, gdy zbliżysz się do wydania lub innego punktu kontrolnego, takiego jak koniec przebiegu. Nadaj tej gałęzi jasną nazwę kojarzącą ją z wydaniem, na przykład release/20.

Utwórz gałęzie, aby naprawić usterki z gałęzi wydania i scalić je z powrotem z gałęzią wydania w żądaniu ściągnięcie.

image of release branch workflows

Port zmienia się z powrotem na główną gałąź

Upewnij się, że poprawki trafią zarówno do gałęzi wydania, jak i gałęzi main. Jednym z podejść jest wprowadzić poprawki w gałęzi wydania, a następnie wprowadzić zmiany w gałęzi main, aby zapobiec regresji w kodzie. Innym podejściem (i tym, które jest stosowane przez zespół Azure DevOps) jest zawsze wprowadzanie zmian w głównej linii, a następnie przenoszenie ich do gałęzi wydania. Możesz przeczytać więcej na temat naszej strategii Flow wersji.

W tym temacie owiesz się, jak wprowadzać zmiany w gałęzi wydania i przenoszenia ich do głównej linii. Zamiast scalania należy używać do wybierania wsadowego, aby mieć dokładną kontrolę nad tym, które zatwierdzenia są ponownie przenoszone do gałęzi głównej. Scalanie gałęzi funkcji z gałęzią główną może wprowadzać zmiany specyficzne dla wydania, których nie chcesz wprowadzać w gałęzi main.

Zaktualizuj gałąź główną za pomocą zmiany wprowadzonej w gałęzi wydania, aby wykonać następujące kroki:

  1. Utwórz nową gałąź funkcji poza gałęzią główną, aby wprowadzić zmiany.
  2. Wybierz zmiany z gałęzi wydania do nowej gałęzi funkcji.
  3. Scal gałąź funkcji z powrotem z gałęzią main w drugim żądaniu ściągnięcie.

Updated release branch workflows.

Ten przepływ pracy gałęzi wydania zachowuje filary podstawowego przepływu pracy bez zmian: gałęzie funkcji, żądania ściągnięcie i silna gałąź główna, która zawsze ma najnowszą wersję kodu.

Dlaczego nie używać tagów do wydań?

Inne przepływy pracy rozgałęzień używają tagów usługi Git do oznaczania określonego zatwierdzenia jako wydania. Tagi są przydatne do oznaczania punktów w historii jako ważnych. Tagi wprowadzają w przepływie pracy dodatkowe kroki, które nie są konieczne, jeśli używasz gałęzi w swoich wydaniach.

Tagi są utrzymywane i wypychane niezależnie od zatwierdzeń. Członkowie zespołu mogą łatwo pominąć tagowanie zatwierdzenia, a następnie wrócić do historii, aby naprawić tag. Możesz również zapomnieć o dodatkowym kroku wypychania tagu, pozostawiając następnego dewelopera pracującego ze starszą wersją kodu podczas obsługi wydania.

Strategia gałęzi wydania rozszerza podstawowy przepływ pracy gałęzi funkcji w celu obsługi wydań. Twój zespół nie musi przyjąć żadnego nowego procesu kontroli wersji innego niż wybór wersji w celu zmiany portu.

Zarządzanie wdrożeniami

Wiele wdrożeń kodu można obsługiwać w taki sam sposób, jak wiele wydań. Utwórz czytelną konwencję nazewnictwa, taką jak wdrażanie/test wydajnościowy,i traktuj gałęzie środowiska jak gałęzie wydań. Twój zespół powinien wyrazić zgodę na proces aktualizowania gałęzi wdrożenia przy użyciu kodu z gałęzi main. Poprawki usterek związane z podstawowym wybieraniem w gałęzi wdrożenia z powrotem do gałęzi main. Należy wykonać te same kroki co przenoszenie zmian z gałęzi wydania.

Wyjątkiem od tego zalecenia jest użycie formy ciągłego wdrażania. Użyj Azure Pipelines podczas pracy z ciągłym wdrażaniem, aby promować kompilacje z gałęzi głównej do celów wdrożenia.

Filmy wideo