Dobra konwencja nazewnictwa dla nazwanych oddziałów w wybranym przez Ciebie {DVCS}

16

Powoli integrujemy Mercurial w naszym biurze i przy tworzeniu stron internetowych zaczęliśmy używać nazwanych oddziałów.

Jednak nie udało nam się znaleźć dobrej konwencji, jeśli chodzi o nazewnictwo naszych oddziałów.

Próbowaliśmy:

FeatureName (widać, że powoduje to problem w dalszej linii)
DEVInitial_FeatureName (Może się mylić, gdy programista przyjdzie i zejdzie po linii)
{uniqueID (int)} _ Feature

Jak do tej pory zwycięża unikatowa_nazwa_identyfikacji, myślimy o utrzymaniu jej w małej bazie danych tylko w celach informacyjnych.

Miałby: branchID (int), featureName (varchar), featureDescription (varchar), data, kto itp ...

To dałoby nam gałęzie, takie jak: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... i mielibyśmy łatwe odniesienie do tego, co robi ta gałąź, bez konieczności sprawdzania dziennika.

Jakieś lepsze rozwiązanie?

version-control mercurial

— jfrobishow
źródło

14

Jeśli nie masz modułu do śledzenia problemów, zalecamy jego skonfigurowanie, a następnie użycie {nazwa modułu do śledzenia problemów} _ {numer biletu}. Kiedy ktoś za jakiś czas zgłosi błąd i nie wiesz dokładnie, jak ta funkcja powinna działać, łatwo będzie dodać adnotację do pliku i wrócić do miejsca, w którym użytkownik mógł zażądać tej dokładnej funkcjonalności.

— Asa Ayers
źródło

Zgadzamy się, że mamy program do śledzenia błędów i planujemy użyć identyfikatora błędu w nazwie oddziału w celu naprawy błędów. Moje pytanie dotyczyło zupełnie nowego rozwoju, gdy nie naprawiasz niczego, ale dodajesz coś zupełnie nowego. Przypuszczam, że moglibyśmy stworzyć głupi bilet na ulepszenie i zacząć stamtąd.

— jfrobishow

5

Absolutnie powinieneś tworzyć bilety na nowe funkcje. Są też prace do śledzenia. +1 za wymaganie unikalnego identyfikatora.

— AShelly

Jeśli upewnisz się, że umieściłeś wszystkie szczegóły nowych funkcji w narzędziu do śledzenia, ktoś może później sprawdzić, czy działa on zgodnie z przeznaczeniem, czy też naprawdę występuje błąd. Pracuję w zespole programistów, który utrzymuje program w wieku 5+ lat. Są chwile, kiedy klient zgłasza błąd, a kiedy go badamy, okazuje się, że działa on zgodnie z przeznaczeniem, a zarówno pierwotny programista, jak i pierwotny requester zniknęli. Mamy podobne sytuacje, w których nie wiemy, dlaczego coś jest tak, a gdyby nie funkcje w module śledzącym, nie moglibyśmy się tego dowiedzieć.

— Asa Ayers

2

Proponuję zachować prostotę i nazwać gałęzie zgodnie z FeatureName(lubfeature-name konwencją ). Tak, oznacza to wspólną przestrzeń nazw, ale w rzeczywistości rzadko stanowi to problem. Po zakończeniu operacji i całkowitym scaleniu z linią główną gałąź można bezpiecznie usunąć.

Główną ideą rozproszonej kontroli wersji jest to, że powinna być łatwa do rozgałęzienia, wprowadzenie dodatkowej biurokracji, takiej jak obowiązkowy unikalny identyfikator, tylko utrudni to.

— Adam Byrtek
źródło

1

Zgadzam się, to jest ta droga. W jakim świecie miałbyś kiedykolwiek tyle oddziałów, że nie można uniknąć kolizji?

— alternatywny

Szczerze mówiąc, powiązanie opisu z nazwą, wydaje mi się, że jest dla nas ważniejsze ... początkowe zatwierdzenie powinno go zawierać, ale nie znam żadnego sposobu na jego szybkie wyodrębnienie.

— jfrobishow

1

W dużym środowisku korporacyjnym pozwolenie programistom na tworzenie nazw funkcji prędzej czy później spowoduje ból głowy.

— AShelly

1

Rozumiem, ponieważ w „dużym środowisku korporacyjnym” nie można ufać programistom. Ale czekaj, tworzą też nazwy zmiennych, funkcji i plików. Powinniśmy również powołać komitet, aby to kontrolować! (ironia)

— Adam Byrtek

2

Polecam użyć takiego formularza (jako przykład):

BUG_ID
BŁĄD # ID
TICKET_ID
BILET # ID
feature_bla-bla-bla
release-x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

Wystarczy wybrać dobre prefiksy (aby umożliwić wyjście filtru z gałęzi hg ), regułę wielkich liter i ogranicznik między prefiksem a identyfikatorem / nazwami.

— gavenkoa
źródło

+1 ostatecznie poszliśmy z BUGID_ {freeCamelCasedTextDescription} na końcu.

— jfrobishow