Co jest lepsze w przypadku drobnych poprawek błędów i drobnych funkcji - nazywanie gałęzi według numeru biletu lub nazywanie ich według opisu funkcji?

Jestem w trakcie sporu (oczywiście serdecznego) z moim tropem dotyczącym prawidłowego nazewnictwa gałęzi. Dotyczy to naprawy błędów i małych gałęzi funkcji, a nie długotrwałych gałęzi funkcji. W przypadku długo działających gałęzi funkcji zgadzamy się, że nazwy czytelne dla ludzi są lepsze. Oto dwa punkty widzenia:

Moje:

Nazwy oddziałów według ich zespołu i numeru biletu są lepsze. Ułatwia to ich znalezienie w naszym systemie biletowym i jest krótszy do pisania. Ułatwia także wyszukiwanie odpowiednich oddziałów w GIT, gdy szukasz historycznych informacji o bilecie.

Przykład:

team-name/12345
team-name/53719

Jego:

Nazewnictwo gałęzi według ich funkcji / funkcjonalności. Ułatwia autouzupełnianie i jest łatwiejszy do zapamiętania niż poszczególne liczby.

Przykład:

team-name/fix-that-sql-bug
team-name/expand-http-parser

Jeden kompromis, który zaproponowałem, to:

team-name/12345-fix-that-sql-bug

Ale to mu się nie podoba, ponieważ bałagan z autouzupełnianiem GIT.

Jeśli opiera się to głównie na opiniach, proszę dać mi wskazówki, jak to lepiej dopasować do SO - ale myślę, że podane przeze mnie przyczyny można zmienić / dodać, aby dać odpowiedź empiryczną.

W tym przypadku wydaje się, że oboje moglibyście pójść na kompromis w sprawie konwencji nazewnictwa, która ma zarówno numer, jak i opis:

Przykład:

team-name / (12345) -fix-that-sql-bug

team-name / (53719) -expand-http-parser

Naprawdę nie ma tutaj poprawnej odpowiedzi, jest ona subiektywna w zależności od twojego punktu widzenia.

Ale jeśli oboje pójdziecie na kompromis, otrzymacie to, co najlepsze z obu światów. Staram się o tym pamiętać, gdy mamy podobne spory w moim zespole.

Edytować:

Aby poradzić sobie z problemem autouzupełniania, możesz wstawić numerowany identyfikator w nawiasach, w ten sposób, gdy zaczniesz wpisywać gałąź, którą zawsze wpisujesz (aby zobaczyć gałęzie. Z tej listy będziesz mógł zobaczyć numerowany identyfikator i opis. Wystarczy wpisać kilka cyfr, tab, a będzie

To naprawdę nie ma znaczenia, dopóki istnieje spójny system, który wszyscy się zgadzają i rozumieją.

Powiedziałbym jednak, że wybranie numeru biletu sprawiłoby, że łatwiej byłoby zapamiętać, nad którym działem pracować. Ponieważ bezpośrednio wiążą się z numerem wydania, a nie z opisem. Samo opisywanie sprawia, że ​​trudniej jest przypomnieć sobie, jaki konkretnie problem powinien być, i może stać się rozwlekły, próbując uniknąć niejasności.

team-name/bug-that-has-specific-circumstances-to-occur-and-takes-alot-to-describe

Nazywanie czegoś wyłącznie po to, by skorzystać z autouzupełniania, jest głupie.

Zgadzam się, że link do narzędzia do śledzenia błędów jest ważny (ważniejszy niż dobre imię, ponieważ określa dokładnie problem rozwiązywany przez oddział, którego nie ma kilka słów), ale jednocześnie jego użyteczność nie oczekuje od ludzi poznać różnicę między błędem # 7312 i # 7213. Nie można też oczekiwać od ludzi, że za każdym razem będą poprawnie poprawiać liczby - pewnego dnia ktoś podejmie się do niewłaściwej gałęzi, ponieważ źle odczytał / wpisał 7312 dla 7213. (ktoś z mojego zespołu zrobił to dzisiaj!)

Więc zrób oba - numeruj gałąź i dodaj bardzo krótki opis tekstowy, aby działał jako czek. Chciałbym umieścić numer na pierwszym miejscu - do cholery autouzupełnianie - ponieważ i tak musisz znać tekst oddziału (np. „Błąd-naprawa-na serwer” lub „naprawa-błąd-na serwer” - nadal musisz wiedzieć jeśli zaczyna się na f lub b!)