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).
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
7 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
Konwencje nazewnictwa gałęzi
Grupa tokenów
Użyj znaczników grupowania przed nazwą oddziału.
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:
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ś.
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.
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.
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.
(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:
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ń.
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 . Bardziej pomocne może okazać się wyświetlanie komunikatów o scalaniu jako , a nie tylko jako
Anonimowy użytkownik
Potwierdzenie od:
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
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
Potwierdzenie od:
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 są bardziej użyteczne: zawiera tylko listy długowiecznych gałęzi i aktywnych gałęzi tematycznych, a nie wszystkie.
Anonimowy użytkownik
Potwierdzenie od:
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
Potwierdzenie od:
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 . 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 , cała historia gałęzi będzie nadal istnieć, jeśli kiedykolwiek będziesz jej potrzebować.
Anonimowy użytkownik
Potwierdzenie od:
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 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
Potwierdzenie od:
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/