Jakie są przykłady powszechnie używanych technik nazywania gałęzi git?

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

Konwencje nazewnictwa gałęzi

• Użyj znaczników grupowania (słów) na początku nazw oddziałów.
• Identyfikuj i używaj krótkich znaczników potencjalnych klientów, aby rozróżniać gałęzie w sposób, który ma sens dla Twojego przepływu pracy.
• Użyj ukośników, aby oddzielić części nazw gałęzi.
• Nie używaj samych liczb jako wiodących części.
• Unikaj długich, opisowych nazw dla długowiecznych gałęzi.

Grupa tokenów

Użyj znaczników grupowania przed nazwą oddziału.

group1/foo

group2/foo

group1/bar

group2/bar

group3/bar

group1/baz

Grupom można nadawać dowolne nazwy, które pasują do Twojego przepływu pracy. Lubię używać krótkich rzeczowników dla swojego imienia. Czytaj dalej, aby uzyskać większą jasność.

Krótkie, dobrze zdefiniowane tokeny

Wybierz krótkie znaczniki, aby nie dodawały zbyt dużego szumu do każdej z nazw 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 znaczników może służyć do określenia, 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 zmian. Nie wiem, jakie są Twoje pętle, ale załóżmy, że są „nowe”, „testowane” i „zweryfikowane”. Możesz nazwać swoje gałęzie skróconymi wersjami tych tagów, zawsze pisanymi tak samo, aby je zgrupować i przypomnieć Ci, gdzie jesteś.

new/frabnotz

new/foo

new/bar

test/foo

test/frabnotz

ver/foo

Możesz szybko zidentyfikować, które gałęzie osiągnęły poszczególne etapy i możesz je łatwo zgrupować za pomocą opcji dopasowywania 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żyć prawie każdego separatora, jaki lubisz w nazwach gałęzi, ale uważam, że najbardziej elastyczne są ukośniki. Możesz użyć myślników lub kropek. Ale ukośniki pozwalają na 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 w przypadku rozwijania tabulatorów (uzupełniania poleceń) w mojej powłoce. Po skonfigurowaniu mogę wyszukiwać gałęzie z różnymi podziałami, wpisując pierwsze znaki części i naciskając klawisz TAB. Następnie Zsh podaje mi listę gałęzi, które odpowiadają części znacznika, którą wprowadziłem. Działa to zarówno dla poprzednich tokenów, jak i wbudowanych.

$ 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 kątem wypełniania poleceń, mogę go również skonfigurować tak, aby obsługiwał myślniki, podkreślenia lub kropki w ten sam sposób. Ale wolę tego nie robić).
Pozwala również na wyszukiwanie gałęzi w wielu poleceniach git, na przykład:

git branch --list "feature/*"

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

gitk --branches="feature/*"

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

Nie używaj samych liczb

Nie używaj samych liczb (ani liczb szesnastkowych) w schemacie nazewnictwa gałęzi. W zakładce rozszerzenia nazwy linku, git może zdecydować, że numer jest częścią sha-1 zamiast nazwy gałęzi. Na przykład mój tracker problemów nazywa błędy jako liczby dziesiętne. Nazywam moje rodzeństwo CRnnnnn, a nie tylko nnnnn, aby uniknąć nieporozumień.

$ git checkout CR15032<TAB>

Menu: fix/CR15032 test/CR15032

Gdybym próbował rozszerzyć tylko 15032, git nie byłby pewien, czy chcę szukać SHA-1 lub nazw gałęzi, a mój wybór byłby nieco ograniczony.

Unikaj długich nazw opisowych

Długie nazwy gałęzi mogą być bardzo pomocne podczas przeglądania listy oddziałów. Ale może przeszkadzać, patrząc na udekorowane jednowierszowe kłody, ponieważ nazwy gałęzi mogą zjadać większość pojedynczego wiersza i skrócić widoczną część kłody.
Z drugiej strony, długie nazwy gałęzi mogą być bardziej przydatne w „scalaniu zatwierdzeń”, jeśli nie masz w zwyczaju przepisywania ich ręcznie. Domyślny komunikat zatwierdzenia scalania to

Merge branch 'branch-name'

. Bardziej pomocne może okazać się wyświetlanie komunikatów o scalaniu jako

Merge branch 'fix/CR15032/crash-when-unformatted-disk-insert'

, a nie tylko jako

Merge branch 'fix/CR15032' . 

Udany model rozgałęzienia Git
http://nvie.com/posts/a-succes ... odel/
Vincent Driessen ma dobre sugestie. Poniżej zdjęcie. Jeśli podoba ci się ten wzór rozgałęzień, rozważ

rozszerzenie strumienia do git
https://github.com/nvie/gitflow/tree/master... Inni

skomentował sytuację przepływu
http://jeffkreeftmeijer.com/20 ... flow/
Model Driessena obejmuje

• Gałąź główna tylko do wydania. Typowa nazwa to

  master

  .
• „rozwinąć” gałąź z tej gałęzi. To jest ten, który jest używany do większości prac bagażnika. Zwykle nazywane

  develop

  .
• Kilka gałęzi funkcji z branży deweloperskiej. Nazwa oparta na nazwie obiektu. Zostaną włączone z powrotem do wersji rozwojowej, a nie w gałęzi master lub release.
• Zwolnij gałąź, aby przechowywać potencjalne wydania, tylko z poprawkami błędów i bez nowych funkcji. Typowa nazwa to

  rc1.1

  .

Poprawki to krótkotrwałe gałęzie dla zmian, które pochodzą od mastera i zostaną przeniesione do mastera bez angażowania gałęzi rozwojowej.
https://i.stack.imgur.com/tjJCt.png

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, rozpoczynam wiersz tematu komunikatu o zatwierdzeniu w pierwszym zatwierdzeniu w tej gałęzi od „Branch:” i dołączam dalsze wyjaśnienia w treści wiadomości, jeśli temat nie daje mi wystarczająco dużo miejsca.
Nazwa gałęzi, której używam, jest tylko deskryptorem odnoszącym się do gałęzi tematu podczas pracy nad nią. Gdy motyw gałęzi jest gotowy, pozbywam się nazwy gałęzi, czasami oflagowując zatwierdzenie do późniejszego wykorzystania.
Dzięki temu dane wyjściowe

git branch

są bardziej użyteczne: zawiera tylko listy długowiecznych gałęzi i aktywnych gałęzi tematycznych, a nie wszystkie.

Miksowałem i dopasowałem z różnych obwodów, które widziałem i w oparciu o narzędzia, których używam. Więc moja pełna nazwa oddziału brzmiałaby:

name/feature/issue-tracker-number/short-description

do przetłumaczenia na:

mike/blogs/RSSI-12/logo-fix

Części są oddzielone ukośnikami, ponieważ są one interpretowane jako foldery w SourceTree dla łatwej organizacji. Używamy Jira do śledzenia naszych problemów, więc podanie numeru ułatwia znalezienie systemu. Uwzględnienie tego numeru umożliwia również wyszukiwanie podczas próby znalezienia tego problemu w Github podczas próby przesłania żądania ściągnięcia.

Dlaczego każde zadanie wymaga trzech rozgałęzień/połączeń? Czy mógłbyś 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 gałęzi. Dzięki temu nazwy gałęzi będą unikalne i możesz dodać do nich krótkie i opisowe słowo lub dwa, aby uczynić je czytelnymi dla człowieka, na przykład

„ResizeWindow-43523”

. Pomaga to również w ułatwieniu pracy, gdy idziesz do czyszczenia gałęzi, ponieważ możesz znaleźć powiązany błąd. Tak zwykle nazywam swoje gałęzie.
Ponieważ te gałęzie są ostatecznie scalane z powrotem w główne, ich usunięcie po scaleniu powinno być bezpieczne. Jeśli nie połączysz się z

--squash

, cała historia gałęzi będzie nadal istnieć, jeśli kiedykolwiek będziesz jej potrzebować.

Zwróć uwagę, jak pokazano na

commit e703d7
https://github.com/git/git/com ... 00b18
lub

commit b6c2a0d
https://github.com/git/git/com ... 8ae84
(Marzec 2014) Teraz, jako część Git 2.0, znajdziesz inną konwencję nazewnictwa (którą można zastosować do gałęzi).

„Kiedy potrzebujesz spacji, użyj myślnika” to dziwny sposób na powiedzenie, że nie powinieneś używać spacji.

Ponieważ w opisach wiersza poleceń częściej używa się przerywanych słów wielokrotnych, nie chcesz nawet używać spacji w tych miejscach.

Nazwa oddziału nie może zawierać spacji (patrz sekcja "

jakie znaki są nieprawidłowe w nazwie oddziału?
https://stackoverflow.com/a/3651867/6309
"i

git check-ref-format

man page
http://git-scm.com/docs/git-check-ref-format
).
Dlatego dla każdej nazwy gałęzi, która byłaby niejednoznacznym wyrażeniem, dobrym pomysłem jest użycie „

-

” (myślnika) jako separatora.

Idąc za sugestią Farktronix, użyliśmy numerów biletów Jira dla podobnych w Mercurial i planuję nadal używać ich w gałęziach git. Ale myślę, że sam numer biletu jest prawdopodobnie dość wyjątkowy. Chociaż byłoby pomocne mieć opisowe słowo w nazwie gałęzi, jak zauważył Farktronix, jeśli przełączasz się między gałęziami wystarczająco często, prawdopodobnie chcesz mniej wpisywać. Następnie, jeśli chcesz znać nazwę partnera, poszukaj w Jira odpowiednich słów kluczowych na bilecie, jeśli ich nie znasz. Dodatkowo w każdym komentarzu musisz podać numer biletu.
Jeśli Twoja gałąź reprezentuje wersję, wydaje się, że ogólną konwencją jest używanie formatu xxx (na przykład: „1.0.0”) dla nazw gałęzi i vx.xx (na przykład „v1.0.0”) dla nazw tagów (aby uniknąć konfliktów) ... Zobacz też:

is-there-an-standard-naming-convention-for-git-tags
https://coderoad.ru/2006265/