Odpowiedzi:
Narzędzia kontroli wersji są na tyle potężne, że pozwalają zobaczyć, jakie pliki zostały zmodyfikowane i jakie metody zostały dodane. Oznacza to, że ogólnie wiadomości dziennika, które w oczywisty sposób powielają to, co już istnieje, zanieczyszczają dziennik.
Dodano somefuncmetodę spełnienia wymagania, tj .:
Oznacza to, że komunikaty w dzienniku muszą raczej wyjaśniać, które funkcje / błędy zostały naruszone lub jaki był cel refaktoryzacji.
Nie zapomnij dodać NUMERU BILETU / WYDANIA .
Jeśli masz jakąś funkcję lub system śledzenia problemów z biletem # lub problemem # , pamiętaj o wpisaniu tego identyfikatora # w zatwierdzeniu. Pomoże to każdemu, kto chce dowiedzieć się więcej o funkcji lub problemie, nad którym pracowałeś.
W moim ostatnim projekcie opracowano makro, aby upewnić się, że pierwsze 7 cyfr komentarza jest prawidłowym numerem wydania z jasnego poszukiwania (nasz system śledzenia problemów / funkcji).
Robię tego typu rzeczy, gdy popełniam np. Naprawę wady, która wymagała zmian w wielu plikach. Ułatwia to stwierdzenie, co się zmieniło, bez patrzenia na poszczególne pliki w zestawie zmian.
W przypadku zestawów zmian pojedynczych plików jest to niepotrzebne.
Pierwszy wiersz to zawsze ogólny opis zestawu zmian, na przykład link do usterki lub historii użytkownika.
Jeśli jest to odpowiednia informacja w narracji komunikatu zatwierdzenia, to tak, dołącz ją. Jeśli jedynym bitem informacji jest sama nazwa pliku, to nie.
Na przykład ma to sens: „Przeniesiono funkcję build_foo () z fooutil.c do foobase.c, ponieważ większość programów, które chcą korzystać z build_foo (), już zawiera foobase.c”
Ten nie: „Zaktualizowałem build_foo () w fooutil.c, aby pobrać parametr bar.”
Chcę tutaj dodać inną perspektywę.
Moja odpowiedź brzmi „tak” lub „nie”, ale ogólnie powiedziałbym „tak”.
Kontrola wersji jest rzeczywiście wystarczająco potężna, aby wiedzieć, który plik jest aktualizowany. Ale kiedy to zrobimy
$ git log
Widzimy tylko komunikat zatwierdzenia. To właśnie robi większość ludzi.
Zaglądając do samego dziennika. Dodaje do tego dodatkowy kontekst. Na przykład:
readme.md: Fix typo detected by language tool
Jest lepszy niż
Fix typo detected by language tool
Jeśli jednak zmiany powodują odrodzenie wielu plików, to przynajmniej wspomnij o edytowanym komponencie.
API: Fix reset password not sent email to user
Po jego odczytaniu wiemy, że naprawiany błąd dotyczy komponentu API i prawdopodobnie znajduje się w katalogu API u podstawy kodu.
Możemy jednak zrobić
$ git show COMMIT_ID --name-only
ale dodaje więcej kroków tylko po to, aby uzyskać pliki.
Jedyny raz, kiedy widziałem, że jest to przydatne w przypadku pojedynczego sprawdzania pliku, to jeśli dokonałeś zmian w funkcji używanej w wielu miejscach w pliku, w wyniku czego różnice są zaśmiecone. Nawet wtedy najpierw umieściłem numer śledzenia zmian i zwykły tekstowy opis zmiany.
Myślę, że prawdziwym pytaniem jest, jak ograniczony jest zakres twoich zobowiązań? Jeśli czekasz na zatwierdzenie różnych niezwiązanych ze sobą zmian w jednym zatwierdzeniu, możesz poczuć potrzebę określenia, które pliki zostały zmienione w jakim celu.
Jeśli jednak po prostu częściej dokonujesz wąskich zatwierdzeń, pojedyncze zatwierdzenie wyjaśni, które pliki zostały zmodyfikowane, i możesz po prostu opisać, jaki był cel komunikatu.
Więcej zobowiązań, częściej. W ten sposób możesz uniknąć bycia tak gadatliwym w swoich wiadomościach.