Jakie są przykłady często używanych praktyk nazywania gałęzi git? [Zamknięte]

Od kilku miesięcy korzystam z lokalnego repozytorium git współdziałającego z repozytorium CVS mojej grupy. Zrobiłem prawie neurotyczną liczbę gałęzi, z których większość na szczęście wróciła do mojego pnia. Ale nazewnictwo zaczyna być problemem. Jeśli mam zadanie, które można łatwo nazwać prostą etykietą, ale wykonuję je w trzech etapach, z których każdy obejmuje własną gałąź i sytuację scalania, to mogę powtórzyć nazwę gałęzi za każdym razem, ale historia jest nieco myląca. Jeśli otrzymam bardziej szczegółowe nazwy, z osobnym opisem dla każdego etapu, nazwy gałęzi zaczną być długie i nieporęczne.

Nauczyłem się, przeglądając tutaj stare wątki, że mogę zacząć nazywać gałęzie za pomocą / w nazwie, tj. Temat / zadanie lub coś w tym rodzaju. Mogę zacząć to robić i sprawdzać, czy to pomaga lepiej zorganizować sytuację.

Jakie są najlepsze praktyki nazywania gałęzi git?

Edycja: nikt tak naprawdę nie zaproponował żadnych konwencji nazewnictwa. Usuwam gałęzie, kiedy skończę z nimi. Po prostu zdarza mi się mieć kilka osób ze względu na to, że kierownictwo stale dostosowuje moje priorytety. :) Jako przykład tego, dlaczego mogę potrzebować więcej niż jednej gałęzi w zadaniu, załóżmy, że muszę przekazać pierwszy dyskretny kamień milowy w zadaniu do repozytorium CVS grupy. W tym momencie, z powodu mojej niedoskonałej interakcji z CVS, wykonałem to zatwierdzenie, a następnie zabiłem tę gałąź. (Widziałem zbyt wiele dziwności w interakcjach z CVS, jeśli w tym momencie próbuję nadal używać tej samej gałęzi).

Oto niektóre konwencje nazewnictwa gałęzi, których używam i ich uzasadnienie

Konwencje nazewnictwa oddziałów

1. Użyj tokenów grupujących (słów) na początku nazw oddziałów.
2. Zdefiniuj i używaj krótkich tokenów potencjalnych klientów, aby rozróżniać gałęzie w sposób istotny dla przepływu pracy.
3. Użyj ukośników, aby oddzielić części nazw oddziałów.
4. Nie używaj nagich liczb jako wiodących części.
5. Unikaj długich opisowych nazw dla długowiecznych gałęzi.

Tokeny grupowe

Użyj tokenów „grupujących” przed nazwami swoich oddziałów.

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

Grupy można nazwać dowolnie, aby dopasować je do przepływu pracy. Lubię używać moich rzeczowników krótkich. Czytaj dalej dla większej przejrzystości.

Krótkie, dobrze zdefiniowane tokeny

Wybierz krótkie tokeny, aby nie dodawały zbyt wiele hałasu do każdej nazwy Twojej gałęzi. Używam tych:

wip       Works in progress; stuff I know won't be finished soon
feat      Feature I'm adding or expanding
bug       Bug fix or experiment
junk      Throwaway branch created to experiment

Każdy z tych tokenów może służyć do informowania, do której części przepływu pracy należy każda gałąź.

Wygląda na to, że masz wiele gałęzi dla różnych cykli zmiany. Nie wiem, jakie są twoje cykle, ale załóżmy, że są one „nowe”, „testowane” i „zweryfikowane”. Możesz nazwać swoje gałęzie skróconymi wersjami tych tagów, zawsze pisanymi w ten sam sposób, aby pogrupować je i przypomnieć, na jakim etapie jesteś.

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

Możesz szybko stwierdzić, które gałęzie osiągnęły poszczególne etapy, i możesz je łatwo grupować, korzystając z opcji dopasowania wzorców Gita.

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

Użyj ukośników, aby oddzielić części

Możesz używać większości dowolnych ograniczników w nazwach gałęzi, ale uważam, że ukośniki są najbardziej elastyczne. Wolisz używać myślników lub kropek. Ale ukośniki umożliwiają zmianę nazwy gałęzi podczas wypychania lub pobierania do / z pilota.

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

Dla mnie ukośniki działają również lepiej dla rozwijania tabulatorów (wykonywania poleceń) w mojej powłoce. Sposób, w jaki go skonfigurowałem, pozwala wyszukiwać gałęzie z różnymi pod-częściami, wpisując pierwsze znaki części i naciskając klawisz TAB. Następnie Zsh podaje mi listę rozgałęzień pasujących do wpisanego przeze mnie tokena. Działa to zarówno z poprzednimi, jak i osadzonymi tokenami.

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell jest bardzo konfigurowalny pod względem wykonywania poleceń i mógłbym również skonfigurować go tak, aby obsługiwał myślniki, podkreślenia lub kropki w ten sam sposób. Ale nie chcę.)

Pozwala także wyszukiwać gałęzie w wielu poleceniach git, takich jak:

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*" 

Zastrzeżenie: Jak Slipp wskazuje w komentarzach, ukośniki mogą powodować problemy. Ponieważ gałęzie są implementowane jako ścieżki, nie można mieć gałęzi o nazwie „foo” i innej gałęzi o nazwie „foo / bar”. Może to być mylące dla nowych użytkowników.

Nie używaj nagich liczb

Nie używaj nagich liczb (lub liczb szesnastkowych) jako części schematu nazewnictwa gałęzi. W rozszerzaniu tabulatora nazwy referencyjnej git może zdecydować, że liczba jest częścią sha-1 zamiast nazwy gałęzi. Na przykład mój moduł śledzenia problemów nazwał błędy liczbami dziesiętnymi. Nazywam moje powiązane gałęzie CRnnnnn, a nie tylko nnnnn, aby uniknąć zamieszania.

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

Gdybym próbował rozwinąć tylko 15032, git nie byłby pewien, czy chciałbym wyszukać SHA-1 lub nazwy gałęzi, a moje wybory byłyby nieco ograniczone.

Unikaj długich opisowych nazw

Długie nazwy gałęzi mogą być bardzo pomocne, gdy patrzysz na listę gałęzi. Ale może to przeszkadzać, gdy patrzy się na zdobione jednowierszowe kłody, ponieważ nazwy gałęzi mogą pochłonąć większość pojedynczej linii i skrócić widoczną część kłody.

Z drugiej strony długie nazwy gałęzi mogą być bardziej pomocne w „zatwierdzaniu scalania”, jeśli zwykle nie przepisujesz ich ręcznie. Domyślny komunikat zatwierdzenia scalania to Merge branch 'branch-name'. Przydatne może być wyświetlanie wiadomości scalania jako Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'zamiast po prostu Merge branch 'fix/CR15032'.

Udany model rozgałęziania Git autorstwa Vincenta Driessena ma dobre sugestie. Zdjęcie jest poniżej. Jeśli ten model rozgałęzień przemawia do ciebie, rozważ rozszerzenie przepływu do git . Inni komentowali przepływ

Model Driessena obejmuje

• Gałąź główna, używana tylko do wydania. Typowa nazwa master.

• Oddział „rozwijający się” z tego oddziału. To jest używane do większości prac na linii głównej. Powszechnie nazywane develop.

• Wiele gałęzi funkcji poza gałęzią programowania. Nazwa oparta na nazwie funkcji. Zostaną one scalone z powrotem w develop, a nie w gałęzie master lub release.

• Gałąź wydań, która przechowuje wersje dla kandydatów, zawierające tylko poprawki błędów i żadnych nowych funkcji. Typowa nazwa rc1.1.

Poprawki to krótkotrwałe gałęzie dla zmian, które pochodzą od wzorca i przejdą do wzorca bez udziału gałęzi programistycznej.

Osobiście wolę usunąć nazwę gałęzi po zakończeniu pracy z gałęzią tematyczną.

Zamiast próbować użyć nazwy gałęzi do wyjaśnienia znaczenia gałęzi, zaczynam temat tematu komunikatu zatwierdzenia w pierwszym zatwierdzeniu w tej gałęzi słowem „Oddział:” i dołączam dalsze wyjaśnienia w treści wiadomości, jeśli temat nie daje mi wystarczająco dużo miejsca.

Nazwa mojej gałęzi jest czystym uchwytem do odwoływania się do gałęzi tematu podczas pracy nad nim. Po zakończeniu pracy nad gałęzią tematów pozbywam się nazwy gałęzi, czasami oznaczając zatwierdzenie do późniejszego wykorzystania.

To sprawia, że ​​dane wyjściowe są również git branchbardziej przydatne: zawiera tylko gałęzie długowieczne i aktywne gałęzie tematyczne, a nie wszystkie gałęzie.

Mieszałem i dopasowywałem z różnych schematów, które widziałem i opartych na oprzyrządowaniu, którego używam.
Więc moja ukończona nazwa oddziału to:

nazwa / funkcja / numer wydania / krótki opis

co przełożyłoby się na:

mike / blogs / RSSI-12 / logo-fix

Części są oddzielone ukośnikami, ponieważ są one interpretowane jako foldery w SourceTree w celu ułatwienia organizacji. Używamy Jira do śledzenia problemów, więc podanie numeru ułatwia wyszukiwanie w systemie. Uwzględnienie tego numeru umożliwia także jego wyszukiwanie podczas próby znalezienia tego problemu w Github podczas próby przesłania żądania ściągnięcia.

Dlaczego dla każdego zadania potrzeba trzech oddziałów / scaleń? Czy możesz wyjaśnić więcej na ten temat?

Jeśli korzystasz z systemu śledzenia błędów, możesz użyć numeru błędu jako części nazwy oddziału. Dzięki temu nazwy gałęzi będą unikalne, a ty możesz poprzedzić je krótkim lub opisowym słowem lub dwoma, aby były czytelne dla ludzi "ResizeWindow-43523". Pomaga to także ułatwić czyszczenie oddziałów, ponieważ można wyszukać związany z nimi błąd. Tak zazwyczaj nazywam swoje oddziały.

Ponieważ te gałęzie ostatecznie łączą się z powrotem w master, powinieneś być bezpieczny, usuwając je po scaleniu. O ile się nie połączysz --squash, cała historia oddziału będzie istnieć, nawet jeśli kiedykolwiek będziesz jej potrzebować.

Uwaga: jak pokazano w zatwierdzeniu e703d7 lub zatwierdzeniu b6c2a0d (marzec 2014 r.), Teraz stanowiącym część Git 2.0, znajdziesz inną konwencję nazewnictwa (którą możesz zastosować do gałęzi).

„Kiedy potrzebujesz użyć spacji, użyj myślnika” to dziwny sposób na powiedzenie, że nie możesz używać spacji.
Ponieważ w opisach wiersza poleceń bardziej powszechne jest używanie wielu przerywanych słów, nie chcesz nawet używać spacji w tych miejscach.

Nazwa oddziału nie może zawierać spacji (patrz „ Które znaki są nielegalne w nazwie oddziału? ” I na git check-ref-formatstronie man ).

Tak więc dla każdej nazwy gałęzi, która byłaby reprezentowana przez wyrażenie składające się z wielu słów, -dobrym pomysłem jest użycie „ ” (myślnika) jako separatora.

Zgodnie z sugestią farktronix, używamy numerów biletów Jira dla podobnych w merkurialu i planuję nadal używać ich do gałęzi git. Ale myślę, że sam numer biletu jest prawdopodobnie wystarczająco unikalny. Chociaż może być pomocne posiadanie opisowego słowa w nazwie gałęzi, jak zauważył farktronix, jeśli przełączasz się między gałęziami wystarczająco często, prawdopodobnie mniej chcesz pisać. Następnie, jeśli chcesz poznać nazwę oddziału, poszukaj w Jira powiązanych słów kluczowych w bilecie, jeśli go nie znasz. Ponadto w każdym komentarzu należy podać numer biletu.

Jeśli twoja gałąź reprezentuje wersję, wydaje się, że powszechną konwencją jest stosowanie formatu xxx (przykład: „1.0.0”) dla nazw gałęzi i vx.xx (przykład „v1.0.0”) dla nazw znaczników (aby uniknąć konfliktu) . Zobacz też: is-there-an-standard-naming-convention-for-git-tags