W pierwszym wierszu komunikatu git commit mam zwyczaj wspominać o pliku, który został zmodyfikowany, jeśli zmiana nie obejmuje wielu plików, na przykład:
Add [somefunc] to [somefile]
Czy to dobrze, czy jest to niepotrzebne?
50
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. Istnieje wiele sposobów na sprawdzenie zawartości zatwierdzenia. Komentarz powinien opisywać cel zatwierdzenia.
źródło
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).
źródło
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.
źródło
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.”
źródło
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
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:
Jest lepszy niż
Jeśli jednak zmiany powodują odrodzenie wielu plików, to przynajmniej wspomnij o edytowanym komponencie.
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ć
ale dodaje więcej kroków tylko po to, aby uzyskać pliki.
źródło
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.
źródło
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.
źródło
Nie powinno
Każdy zainteresowany może zobaczyć zmiany w historii
Jest to również niemożliwe w większych systemach, ponieważ wiele plików może być generowanych automatycznie
źródło