Pisanie komunikatów zatwierdzania jako programista solo?

W moich projektach, w których repozytorium jest udostępniane mi i innym programistom, zawsze piszę komunikaty zatwierdzenia, nawet jeśli jestem głównym programistą.

Ale w tych projektach, w których jestem solowym programistą pracującym nad projektem, a repozytorium jest hostowane na moim osobistym laptopie i nawet nie jest hostowane przez klienta, dlatego nikt oprócz mnie nie widziałby zatwierdzeń, gdybym nadal pisał zatwierdzenie wiadomości?

Do tej pory pisałem je, ale odkryłem, że nigdy nie wróciłem i nie przeglądałem moich wiadomości z zatwierdzeniami. Zapisuję wiadomości, ale nie mam czasu na ich pisanie, ale nigdy więcej ich nie widzę.

Czy są jakieś dobre powody, aby pisać komunikaty zatwierdzania jako programista solo, czy powinieneś je pominąć, aby skupić się na rozwoju?

Oto jeden powód: jeśli nagle zdasz sobie sprawę, że coś zostało zepsute w ciągu ostatnich kilkuset zatwierdzeń (możliwe, jeśli popełniasz przy każdej drobnej edycji, mniej wykonalne, jeśli, podobnie jak ja, robisz tylko „stabilne” migawki), możesz łatwiej dowiedz się, gdzie wstawiłeś błąd, jeśli napisałeś wyraźne komunikaty zatwierdzenia, a nie „poprawki błędów”. (Uważam, że ulubiona struna kolegi). Oczywiście możesz korzystać z svn logdowolnego używanego SCM, ale powinno być łatwiej na odwrót.

Przekazywanie wiadomości zmusza cię również do zastanowienia się, co dokładnie zrobiłeś jako zmianę i, jak sądzę, podsumowując w myślach, jak najlepiej byłoby kontynuować ulepszanie projektu.

Staram się zawsze. Ile razy spoglądasz wstecz i myślisz: „Człowieku, co robiłem, kiedy dokonałem tej zmiany”. Robię cały czas. 30 sekund pisania wiadomości może zaoszczędzić 20 minut pracy, którą trzeba zapamiętać.

Czy szczerze wierzysz, że narzuty związane z pisaniem od 40 do 80 znaków zwykłym angielskim są znaczącym nakładem na zatwierdzenie, czy szukasz wymówki, aby być leniwym?

Być może problem polega na wyrażeniu prostym językiem angielskim, dlaczego dokonałeś zmiany, w takim przypadku może być konieczne sprawdzenie celu zmiany, nawet do pytania, czy naprawdę musisz to zrobić.

Radzę nie sądzić, że ponieważ lecisz sam, możesz złamać zasady. Pozostań profesjonalistą przez cały czas i dodawaj sensowne komunikaty zatwierdzania. Jak zauważyli inni autorzy, pewnego dnia będziesz z tego wdzięczny.

• Nie zawsze będziesz programistą solo.

• W końcu złamiesz bazę kodu i spróbujesz ją przywrócić. Dobre komunikaty zatwierdzania pozwolą Ci zaoszczędzić godziny.

• Nie pamiętasz, nad czym pracowałeś trzy tygodnie temu, prawda?

• Komunikaty zatwierdzania powinny być bardzo jasne. Jeśli tak nie jest, oznacza to, że albo nie zakończyłeś pracy nad zadaniem, albo jedno zadanie rozłożyło się na dwa lub więcej zadań.

Zdecydowanie, w przeciwnym razie korzystanie z funkcji takich jak rozgałęzianie i scalanie będzie znacznie trudniejsze w użyciu. I będzie chciał z nich korzystać, nawet jeśli deweloper solowy.

Jeden z możliwych powodów: zmusza cię do bardziej abstrakcyjnego myślenia o dokonanej właśnie zmianie i do zmiany struktury.

Jeśli wydaje Ci się to bezcelowe, może po prostu skomentuj główne zmiany lub te, które zmieniają istniejącą funkcjonalność, na wypadek, gdybyś kiedykolwiek szukał źródła dziwnego zachowania.

Byłem jedynym podmiotem odpowiedzialnym za projekt TXR i zachowałem szczegółowy dziennik zmian od dość wczesnego etapu projektu. Jest to blisko 11 000 linii i rośnie: http://www.kylheku.com/cgit/txr/tree/ChangeLog

(Komunikaty zatwierdzania w repozytorium są tylko kopią tego, co znajduje się w dzienniku zmian.)

[Edycja 2016: od połowy 2015 r. Nie utrzymuję już pliku ChangeLog; jednak komunikaty zatwierdzania są zapisywane w formacie zgodnym z konwencjami Git i ChangeLog w tym samym czasie. Ten sam poziom szczegółowości istnieje w sposób, który nie powoduje problemów z scalaniem. Plik ChangeLog można mechanicznie zrekonstruować na podstawie tych komentarzy.]

Tak, więcej niż raz wróciłem do starej wiadomości zatwierdzenia związanej ze zmianą, która coś zepsuła (odkryta za pomocą git bisect). Wiadomość pomogła mi zrozumieć, co robię.

W dzienniku zmian możesz określić, kiedy po raz pierwszy wprowadzono funkcję, typ, makro lub zmienną globalną, a następnie zmiany dotknęły jej.

Ale główny powód pisania szczegółowych komunikatów zatwierdzania, takich jak te, podczas samodzielnej pracy, jest następujący: podczas wykonywania tej operacji znajdziesz błędy .

Napisanie szczegółowego komunikatu zatwierdzenia ma podobne zalety jak przegląd kodu twojego zatwierdzenia przez kogoś innego. Wartość przeglądu zatwierdzeń nie polega na tym, że ktoś sprawdza Twój kod, ale na tym, że musisz wyjaśnić swoje zmiany innemu programistowi.

Kiedy próbujesz wyjaśnić rzeczy, czasami okazuje się, że nie mają one sensu.

Kolejny powód: możesz złapać się na bezużytecznej zmianie . Pisząc szczegółowy komentarz zatwierdzenia, uchwycisz ogólny widok tego, co robisz, a następnie czasami stajesz przed faktem, że nie jest to dobra zmiana.

Czasami wprowadzałem zmiany, kiedy w trakcie pisania wpisu ChangeLog zdałem sobie sprawę, że będzie to raczej git reset --hard(wyrzuć te bezużyteczne zmiany) niż git commit -a.

Chociaż nie spotkałeś się jeszcze z potrzebą przeglądania wiadomości zatwierdzania, możesz być im bardzo wdzięczny w przyszłości. Powinieneś pisać je nawet dla siebie. Istnieje wiele powodów, które mogą być przydatne później (zapomniałeś, dlaczego dodajesz funkcję, lokalizujesz brakujące pliki itp.)

Oto powiązane pytanie dotyczące celu komunikatów zatwierdzania: Dlaczego powinienem napisać komunikat zatwierdzenia

Zawsze zatwierdzam sensowną wiadomością o zmianach i robię to często ze zmianami przyrostowymi.

Czy to zawsze najbardziej przydatna rzecz? Nie, nie ma w tym problemu. Jeśli musisz powrócić do poprzedniego etapu, Twoje wiadomości poinformują Cię, gdzie jesteś i co zrobiłeś. Można go również wykorzystać do śledzenia postępów w projekcie. Co do tego, że jest to postrzegane jako strata czasu, czy 30 sekund potrzebnych na zanotowanie zdania jest tak istotne?

Nie widzę żadnej różnicy w zakresie komunikatów zatwierdzania, niezależnie od tego, czy pracujesz w zespole, czy nie. Pamiętasz, co robiłeś tu lub tam przez ograniczony czas, a potem to samo, jakby ktoś inny to napisał. Powinieneś więc pisać wiadomości tak dobrze, jak dla innych ludzi.