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


Od kilku miesięcy korzystam z lokalnego repozytorium git, wchodząc w interakcję z repozytorium CVS mojego zespołu. Zrobiłem prawie neurotyczną liczbę gałęzi, z których większość, na szczęście, weszła z powrotem w mój pień. Ale nazewnictwo zaczyna być problemem. Jeśli mam zadanie, które łatwo nazwać prostą etykietą, ale robię to w trzech krokach, każdy z własną gałęzią i sytuacją scalania, mogę za każdym razem powtarzać nazwę gałęzi, ale to sprawia, że ​​historia jest trochę zagmatwana. Jeśli podam bardziej szczegółowe nazwy, z osobnym opisem dla każdego etapu, nazwy gałęzi zaczną być długie i uciążliwe.
Właściwie, patrząc na stare wątki tutaj, dowiedziałem się, że mogę zacząć nazywać gałęzie od A/w nazwie, tj. Temat/zadanie lub coś w tym rodzaju. Mogę zacząć to robić i zobaczyć, czy pomoże to lepiej zorganizować pracę.
Jakie są wskazówki dotyczące nazywania gałęzi git?
Edytować:
Nikt właściwie nie sugerował żadnych konwencji nazewnictwa.
Usuwam gałęzie, kiedy skończę z nimi. Mam wokół siebie tylko kilka osób, ponieważ kierownictwo nieustannie dostosowuje moje priorytety. :)
Jako przykład, dlaczego mogę potrzebować więcej niż jednej gałęzi w zadaniu, przypuśćmy, że muszę zatwierdzić pierwszy dyskretny kamień milowy w zadaniu do repozytorium grupowego CVS. W tym momencie, z powodu mojej niedoskonałej interakcji z CVS, zatwierdziłbym to zatwierdzenie, a następnie zabiłbym tę gałąź. (Widziałem zbyt wiele dziwnych interakcji z CVS, jeśli spróbuję nadal używać tej samej gałęzi w tym momencie).
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

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' . 
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

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
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

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.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

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.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

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ć.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

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.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

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/

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się