Git oferuje elastyczne strategie rozgałęziania, ale co to oznacza? Krótko mówiąc, strategia rozgałęziania to zestaw reguł, konwencja, która pomaga zespołom i programistom – mogą przestrzegać tych zasad i konwencji, aby utworzyć nową gałąź, jej przepływ itp.
Niestosowanie odpowiednich konwencji nazewnictwa prowadzi do zamieszania i komplikuje zespół zajmujący się obsługą kodu. Nie możemy ignorować najlepszych praktyk Git w zakresie konwencji nazewnictwa rozgałęzień.
Strategie rozgałęziania w Git pozwalają na oddzielenie pracy. Ogólnie rzecz biorąc, możemy podzielić gałęzie Git na dwie kategorie:gałęzie zwykłe i tymczasowe.
Zwykłe gałęzie Git
Te gałęzie będą dostępne w Twoim repozytorium na stałe. Ich konwencja nazewnictwa jest prosta i bezpośrednia.
- Programowanie (programowanie ) jest główną gałęzią rozwoju. Ideą gałęzi deweloperskiej jest wprowadzanie w niej zmian i ograniczanie programistom możliwości bezpośredniego wprowadzania jakichkolwiek zmian w gałęzi głównej. Zmiany w gałęzi dev przechodzą przeglądy i po testach są scalane z gałęzią master.
- Mistrz (mistrz ) to domyślna gałąź dostępna w repozytorium Git. Powinna być stabilna przez cały czas i nie pozwalać na bezpośrednią odprawę. Możesz go scalić dopiero po przeglądzie kodu. Wszyscy członkowie zespołu są odpowiedzialni za utrzymanie stabilności i aktualności mistrza.
- Kontrola jakości (Kontrola jakości ), czyli gałąź testowa, zawiera cały kod do testowania QA i testowania automatyzacji wszystkich wprowadzonych zmian. Zanim jakakolwiek zmiana trafi do środowiska produkcyjnego, musi przejść testy QA, aby uzyskać stabilną bazę kodu.
Tymczasowe gałęzie Git
Jak sama nazwa wskazuje, są to gałęzie, które można tworzyć i usuwać w razie potrzeby. Mogą być następujące:
- Naprawa błędu
- Naprawa na gorąco
- Gałęzie funkcji
- Oddziały eksperymentalne
- Oddziały WIP
Istnieje wiele formatów i konwencji nazewnictwa zalecanych przez ekspertów dla oddziałów tymczasowych.
Oto prosty przepływ pracy z gałęziami Git.
Konwencja nazewnictwa rozgałęzień w Git
W tym artykule omówię i podzielę się siedmioma najlepszymi konwencjami nazewnictwa, z których korzystałem osobiście w przeszłości, aby zapewnić ich skuteczność.
1. Rozpocznij nazwę oddziału słowem grupy
To jedna z najlepszych praktyk. Słowo grupy może być dowolne, aby pasowało do Twojego przepływu pracy.
Lubię krótkie słowa, takie jak:
Błąd – Błąd, który należy wkrótce naprawić
WIP – Prace w toku i mam świadomość, że niedługo się nie skończą
Patrząc na nazwę gałęzi, możesz zrozumieć, o czym jest ta gałąź Git i jaki jest jej cel.
Spójrz na poniższe przykłady:
- bug-logo-alignment-issue – programista próbuje naprawić problem z wyrównaniem logo;
- wip-ioc-container-added – gałąź odnosi się do zadania dodania kontenera IoC w toku.
2. Użyj unikalnego identyfikatora w nazwach oddziałów
Możesz użyć identyfikatora śledzenia problemów w nazwie swojego oddziału. Preferuję tę metodę, gdy pracuję nad naprawą niektórych błędów. Na przykład:
wip-8712-add-testing-module
Nazwa wskazuje, że branch dotyczy zadania dodania modułu testowego, identyfikator śledzenia zgłoszenia to 8712, a prace trwają.
Kolejną zaletą korzystania z zewnętrznego identyfikatora śledzenia w nazwie oddziału jest możliwość śledzenia postępu z zewnętrznego systemu.
3. Użyj myślnika lub ukośnika jako separatorów
Wielu programistów używa ukośnika jako separatora, a wielu używa myślników. Którego użyć – zależy od Ciebie i preferencji Twojego zespołu.
Moim zdaniem myślniki ułatwiają czytanie nazwy, więc jest to odpowiedni separator w nazwach gałęzi. Możesz używać ukośników, łączników i podkreśleń. Chodzi o to, aby być konsekwentnym.
Istnieją dwie główne zalety używania separatora w nazwie gałęzi:
- Zwiększa czytelność i pomaga uniknąć nieporozumień;
- Ułatwia zarządzanie, zwłaszcza jeśli masz do czynienia z wieloma oddziałami.
Przykład 1. Nazwa gałęzi Git bez separatora:
featureupgradejqueryversionloginmodule
Przykład 2. Dodając separator (w tym przypadku jest to podkreślenie), czynisz czytelną nazwę gałęzi Git:
feature_upgrade_jquery_version_login_module
4. Gałąź Git z nazwiskiem autora
Wiele firm woli dodawać nazwiska autorów do nazw oddziałów zgodnie z poniższym formatem:
<author>_<branch-type>_<branch-name>Np. rajeev.bera_feature_new-experimental-changes
Ta metoda pozwala na łatwe śledzenie pracy i postępów różnych programistów za pomocą dodatkowych systemów.
5. Unikaj używania tylko liczb
Niektórzy programiści używają tylko identyfikatora problemu w nazwie gałęzi, co nie jest pomocne w postępie prac.
Na przykład istnieje nazwa oddziału 9912 – co powinien nam powiedzieć ten magiczny numer? Oznacza to tylko więcej zamieszania i ryzyko błędów, zwłaszcza podczas łączenia z innymi gałęziami git.
6. Unikaj jednoczesnego używania wszystkich konwencji nazewnictwa
Mieszanie i dopasowywanie wszystkich konwencji nazewnictwa gałęzi Git nie jest najlepszym rozwiązaniem. To tylko wprowadza zamieszanie i komplikuje cały proces.
Zespół powinien raz ustalić konwencje nazewnictwa, które będą używane w pracy, i się ich trzymać. Spójność jest najważniejsza.
7. Unikaj długich opisowych nazw dla długowiecznych gałęzi
Istotną cechą nazwy oddziału jest to, że powinna być precyzyjna i informacyjna. Przyjrzyjmy się ponownie kilku przykładom:
wip_login_module_which_will_used_in_the_public_website
wip_login_module_which_will_used_in_the_internal_website
Tam nazwy oddziałów są długie i szczegółowe. To nie jest konieczne. Zamiast tego możesz użyć następującego wariantu:
wip_feature_login_module
Ta nazwa jest krótka, ale wyjaśnia cel tej gałęzi.
Wniosek
Model rozgałęzień Git jest potężny, ale musisz prawidłowo i skutecznie zarządzać gałęziami. Jednym z niezbędnych czynników jest przestrzeganie tych samych konwencji przez wszystkie zespoły, w szczególności – konwencji nazewnictwa dla lokalnego repozytorium.
Aby upewnić się, że Twój zespół stosuje uzgodnione konwencje, egzekwuj standardy. Jednym z najprostszych sposobów jest użycie haków Git, takich jak hak przed zatwierdzeniem. Mam nadzieję, że da ci to pojęcie o modelach rozgałęzień Git i ich konwencji nazewnictwa.
