Oto niektóre konwencje nazewnictwa gałęzi, których używam i ich uzasadnienie
Konwencje nazewnictwa oddziałów
- Użyj tokenów grupujących (słów) na początku nazw oddziałów.
- Zdefiniuj i używaj krótkich tokenów potencjalnych klientów, aby rozróżniać gałęzie w sposób istotny dla przepływu pracy.
- Użyj ukośników, aby oddzielić części nazw oddziałów.
- Nie używaj nagich liczb jako wiodących części.
- 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'.
