Czy możesz polecić dobry szablon komunikatu / wytyczne do egzekwowania w firmie? [Zamknięte]

W Git można ustawić i egzekwować dobry szablon zatwierdzania.

Czy możesz polecić (najlepiej z argumentacją) dobry szablon / wytyczne do egzekwowania w firmie?

używam

[Abc]: Message.

Dzięki Add, Mod (ify), Ref (aktorstwo), Fix, Rem (ove) i Rea (dability) łatwo jest wyodrębnić plik dziennika.

Przykład:

Add: New function to rule the world.  
Mod: Add women factor in Domination.ruleTheWorld().  
Ref: Extract empathy stuff to an abstract class.  
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.  
Rem: freeSpeech is not used anymore.  
Rea: Removed old TODO and extra space in header.  

Jeśli mam więcej niż linię, najpierw sortuję je według najważniejszych.

Używamy:

[Identyfikator biletu w JIRA]: [Wiadomość: Co zostało zrobione] Na przykład - ABC-123: Dodano możliwość konfigurowania prezentacji według regionu.

W takim przypadku z odpowiednią integracją będziesz mógł zmieniać / usuwać / dodawać pliki w swoim module do śledzenia problemów. Należy jednak pamiętać, że należy zapobiec coś takiego jak ABC-123: Gotowe lub ABC-123: Naprawiono za pomocą filtrów, jeśli to możliwe.

Istnieje jedna prosta zasada, którą jest konwencja, po której następuje wiele (jeśli nie wszystkie) SCM i większość narzędzi, które działają z SCM:

Pierwszy wiersz komunikatu zatwierdzenia jest krótkim streszczeniem, a reszta wiadomości zawiera szczegóły.

Dlatego większość narzędzi wyświetla tylko pierwszy wiersz i wyświetla całą wiadomość na żądanie.

Typowym niewłaściwym użyciem komunikatu zatwierdzenia jest wypunktowana lista zmian (pokazany zostanie tylko pierwszy punkt). Kolejnym niewłaściwym zastosowaniem jest napisanie długiej, szczegółowej wiadomości w jednym wierszu.

Tak więc, jeśli jest jedna rzecz do narzucenia, powiedziałbym, że jest to maksymalna długość pierwszej linii.

Osobiście nigdy nie widziałem ogólnego szablonu zatwierdzania wartego użycia. Komentarz powinien zwięźle określać, jakie zmiany są związane np. Z jaką funkcją / poprawką błędu lub krótkie stwierdzenie, dlaczego wprowadzono zmiany.

Informacje o tym, co zostało popełnione, nie powinny być dołączane, może to zostać określone przez system SCM. Więcej informacji o błędach / funkcjach znajduje się tam, gdzie kiedykolwiek śledzone są błędy i funkcje.

Podczas aktualizacji raportu o błędzie po zatwierdzeniu uważam, że dobrze jest również podać wersję zatwierdzenia wraz z komentarzami w raporcie o błędzie. W ten sposób możesz znaleźć swoją drogę od komentarza do raportu o błędzie, a dla każdego komentarza w raporcie o błędzie możesz znaleźć to, co zostało popełnione, ale nie powielasz informacji, umieszczając je zarówno w raporcie o błędzie, jak i w komunikacie o zatwierdzeniu.

Następnie, przeglądając historię wersji pliku, masz ładne krótkie wiadomości opisujące historię, ale także wiesz, gdzie szukać więcej szczegółów raportów o błędach lub opisów zadań, aby uzyskać więcej szczegółów.

W Git można egzekwować prawie wszystko za pomocą haków Git . Sprawdź przykłady w .git / hooks, aby znaleźć pomysły.

Jeśli chodzi o wiadomość, w bardzo ogólnym przypadku chcesz podać wystarczającą ilość informacji o rozwiązanym problemie ORAZ samo rozwiązanie, aby móc później znaleźć i zidentyfikować to zatwierdzenie. W większości przypadków problem będzie oznaczony numerem błędu (przy właściwej integracji z systemem śledzenia błędów). Jeśli masz inne systemy, z którymi proces się integruje (np. System śledzenia recenzji kodu), dołącz również odpowiednie bity:

Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.

BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none

ALE chcesz to uprościć. W przeciwnym razie ludzie znajdą sposób na oszukiwanie systemu i generowanie bezużytecznych komunikatów zatwierdzania.

Używamy szablonu zawierającego

• Numer identyfikacyjny błędu / funkcji / poprawki
• Tak / nie opisujące, czy kod jest testowany, czy nie
• I sekcja ze szczegółami dla krótkiego opisu zamiaru zatwierdzenia

Pierwsze dwa są jednak najczęściej pomijane (czasami wszystkie trzy), więc to naprawdę nie jest wielka sprawa.

Zasadniczo mam identyfikator, którego używam w systemie śledzenia biletów lub ogólny przegląd jako pierwszy wiersz. Następnie mam punkty „punktora” w wierszu konkretnej zmiany w zatwierdzeniu. Więc mógłbym coś takiego:

MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity

To najczystszy format zatwierdzania, jaki lubię. Jest to bezpośrednie i na temat. Innym powodem, dla którego robię to w ten sposób, jest to, że jeśli chcę utworzyć dziennik zmian, mogę po prostu wziąć wszystkie komunikaty zmian i bardzo łatwo przeanalizować je w dzienniku zmian.

[ticketId] [ABC] [topicId] [WIP] Wiadomość, gdzie:

• ticketId - identyfikator elementu w repozytorium zadań
• ABC - dodaj (funkcja), popraw (poprawka błędu), str (struktura), dep (zależność) rem (niezgodność wsteczna / usuń), rea (czytelność), ref (refaktoryzacja)
• topicId - może być selektorem zadań dla jenkins i / lub nazwy gałęzi i / lub nazwy tematu dla gerrit
• WIP - praca w toku / nie (tj. Ciągła integracja może tego wymagać)
• wiadomość - szczegół modyfikacji

Przykłady:
[# 452567] [dodaj] [menu_item] nowy element - księga gości
[# 452363] [fix] [banner_top] [WIP] 1024x300 można teraz użyć
[# 452363] [fix] [banner_top] 500x200 można teraz użyć
[ # 452713] [rem] [strona] wyszła środkowa reklama