Dlaczego powinienem napisać komunikat zatwierdzenia?

Dlaczego powinienem napisać komunikat zatwierdzenia? Nie chcę i myślę, że za każdym razem jest to głupie.

Interfejs GUI, którego używam, który pozostanie nienazwany, zmusza cię do tego. Słyszę, że inni robią to za każdym razem, nawet jeśli używają VCS w wierszu poleceń.

Jeśli popełniam kilka razy dziennie i nie ukończyłem funkcji, o czym piszę? TYLKO piszę wiadomość po wielu zatwierdzeniach i czuję, że nadszedł czas na mini tag lub kiedy zrobię prawdziwy tag.

Czy mam rację, czy coś brakuje? również używam systemu rozproszonego

Wszystkim ludziom, którzy mówią: „zatwierdzaj tylko wtedy, gdy masz użyteczną, przemyślaną wiadomość do napisania, a gdy Twoja funkcja jest w 100% ukończona i masz do niej testy jednostkowe”, mówię: Nadal masz nastawienie SVN .

Jeśli używasz git , to właśnie nazwałbym inteligentny przepływ pracy:

1. Zaangażuj się tak często, jak chcesz . Napisz tam jakąkolwiek starą szybką wiadomość. I tak nikt tego nie zobaczy.
2. Po powiedzmy 10 zatwierdzeń, zakończyłeś pracę nad którą pracowałeś. Teraz napisz testy i zatwierdz je. Lub cokolwiek chcesz. Jeśli lubisz TDD, najpierw napisz testy, nie obchodzi mnie to, nie git.
3. git rebase -iod pierwszego „niechlujnego” zatwierdzenia, które dodałeś i naprawiłeś swoją lokalną historię, zgniatając, edytując, pomijając i w inny sposób czyszcząc swoją najnowszą historię w logiczne, czyste zatwierdzenia z ładnymi wiadomościami .
4. Po oczyszczeniu poproś kogoś, aby cię odciągnął.
5. Wypłukać i powtórzyć.

Zauważ, że krok 3 ma miejsce, gdy skończysz z tymi ładnymi zatwierdzeniami, których szukałeś, i że używając SVN będziesz musiał powstrzymać się od zatwierdzania, dopóki nie zrobisz dwóch pierwszych kroków, co sugeruje większość pozostałych odpowiedzi. IOW, nie chcesz narzucać innym w połowie napisanego, nieprzetestowanego kodu innym osobom, więc nie robisz tego przez tydzień, dopóki nie skończysz swojej funkcji. Nie używasz kontroli wersji do pełnego potencjału.

Pamiętaj także, że gdziekolwiek pomiędzy krokami 1 i 3, możesz git pushwprowadzić zmiany w swoim prywatnym lustrze repo na serwerze, aby uzyskać bezpłatne kopie zapasowe, jeśli dysk twardy laptopa zginie.

Ponieważ gdy jakiś słaby opiekun poluje na błąd i stwierdza, że ​​został on dodany w rev. Xyz, będzie chciał wiedzieć, co rev. Xyz miał zrobić.

Komentujesz swój kod źródłowy, prawda?

Piszesz najlepsze komentarze, które mówią dlaczego, ponieważ kod mówi tylko jak ?

Komunikat zatwierdzenia jest takim komentarzem, dlatego jest bardzo ważny i im więcej myślisz o jego poprawnym wykonaniu, tym bardziej jest on użyteczny dla przyszłego opiekuna oprogramowania.

W przypadku każdego aktywnego oprogramowania ten komentarz zostanie wyświetlony w coś podobnego

(znalezione pod adresem http://longair.net/blog/2009/04/25/a-few-git-tips/ ). Pozwala to widok z lotu ptaka , który pracował nad oprogramowaniem kiedy i co zrobili.

Należy pamiętać, że to jest ostatecznym celem zatwierdzenia komentarza, a mianowicie pokazuje się w takiej listy powiedzenie „ co ” do swojej własnej przyszłości lub kolegi, i to jest powód, dlaczego należy dbać w pisanie dobrych popełnić wiadomości.

Jeśli komunikat zatwierdzenia wydaje ci się głupi, oznacza to, że używasz niepoprawnych zatwierdzeń.

Zatwierdzenia powinny być dokonywane z dobrego powodu - powinny być powiązane z zadaniami, które podzieliłeś dla funkcji, nad którą pracujesz. Niezależnie od tego, czy zadania te są formalne, czy tylko w twojej pamięci, każda dokonana zmiana powinna mniej więcej zakończyć zadanie, a zatem być w jakiś sposób funkcjonalna.

Wtedy twoje komunikaty zatwierdzenia służą znacznie lepszemu celowi. Opisz ukończone zadanie, a jeśli nie jest ono śledzone w innym miejscu, dlaczego to zadanie było potrzebne lub do jakiego celu służy:

• Przebudowano klasę użytkownika, aby uzyskać lepszą enkapsulację
• Utworzono kody pośredniczące API, aby interfejsy mogły być używane w klasie kontrolera
• Przekształcił klasę bazy danych w klasę abstrakcyjną, aby w przypadkach testowych można było użyć próbnej bazy danych

Następnie Ty lub inni programiści możecie przeglądać repozytorium lub historię plików i dość łatwo zobaczyć, gdzie nastąpiły pewne ewolucje i dlaczego. Lub, jeśli konkretna wersja zostanie uznana za winną błędu, komunikat zatwierdzenia da wskazówkę, dlaczego ta linia została wstawiona, abyś nie tylko ją rozerwał i możliwe było ponowne rozbicie czegoś, co było uważane za naprawiono, a zamiast tego można to naprawić we właściwy sposób.

Komentarze zatwierdzenia nie rozwiązują wszystkiego. Zawsze istnieje szansa, że ​​mogą wprowadzić w błąd tak samo, jak pomagają - zwłaszcza gdy deweloperzy są źli z powodu konieczności wejścia na nie. Spróbuj tego: pomyśl o nich jak o śladzie okruchów chleba w lesie lub o punktach wspinaczkowych lub pociskach znakujących. Zrobione prawidłowo, mogą nakreślić mylącą ścieżkę.

Nie rób z nich wielkiego interesu. Bądź szczery:

• „Edytowane encje indeksu przestrzennego, Daos i interfejsy użytkownika do obsługi operacji X”
• „Przyrostowe zameldowanie dla żądania funkcji # 1234 i błędu # 5678”
• „Zepsułem ostatnią wersję. Są to pliki, które przegapiłem”.

Mów krótko i „duży obraz”. Jeśli to możliwe, sprawdź numer problemu w swoim systemie funkcji / błędów. Niektóre interfejsy kontroli wersji zawierają pole do tego rodzaju rzeczy.

Zmniejsza liczbę WTF / minutę;)

co przekłada się na szczęśliwszy zespół (który cię nie nienawidzi) i lepszą wydajność zespołu potencjalnie przy niższych kosztach

Tak więc reszta twojego zespołu wie, że WTF robisz sprawdzanie zmian w drzewie projektu.

ponieważ jeśli nie ćwiczysz wprowadzania porządnych wiadomości zatwierdzania, skończysz jak mój kolega, który wprowadza wiadomości takie jak

no changes

lub

testing

dla zatwierdzeń z ponad stu zmienionymi plikami (tutaj nie żartuję !!).

Jeśli zostaniesz takim programistą, będziesz wyglądać głupio w oczach reszty świata, bez względu na to, jak głupio myślisz, po prostu wpisując wiadomość.

Dlaczego popełniasz błędy, jeśli zmiany nie mają znaczenia?

Po prostu zatwierdzaj zmiany, które mają znaczenie. Np. Zrobiłem dość dużą refaktoryzację w drugim tygodniu, co zajęło mi około 3 dni. W tym czasie miałbym mnóstwo zobowiązań. Niektóre były raczej niewielkimi zmianami („przemianowano klasę X na Y, aby odzwierciedlić nową odpowiedzialność” lub „przeniesiono metodę Z () na klasę Q”), a inne były naprawdę duże. Kiedy skończę z funkcją / refaktoryzacją, sprawdzam, czy niektóre zatwierdzenia mogą zostać zmiażdżone (przynajmniej git obsługuje to, nie wiem o innych narzędziach), ale zwykle zostawiam je bez zmian, ponieważ pomaga to później.

Chyba nie popełnilibyście w trakcie edycji linii, więc powinna ona mieć znaczenie. Po prostu opisz, co zrobiłeś od ostatniego zatwierdzenia.

wyobraź sobie sytuację, w której zepsułeś system wprowadzając pewne zmiany i zdaj sobie z tego sprawę po kilku zatwierdzeniach przez zespół. Nie pamiętasz, jaka była zmiana, ale pamiętasz, że coś mogło pójść nie tak, gdy ulepszałeś funkcję X lub usuwałeś plik z modułu Y.

Ale niestety numer wersji nie mówi ci, kiedy zmieniłeś X lub Y. Więc twój wybór albo odczytaj wszystkie kody zatwierdzone w ciągu ostatnich N dni, albo po prostu przeczytaj szczegółowe napisane komunikaty zatwierdzeń (znacznie bardziej czytelne niż kod).

Więc jeśli piszesz ten sam, nudny, bezużyteczny, niepowiązany tekst w komunikacie zatwierdzenia, ponieważ musisz, jest bardziej szkodliwy niż posiadanie komunikatu zatwierdzenia. Ponieważ zamiast znaleźć źródło błędu błędna wiadomość Cię wprowadzi w błąd.

Dlatego staraj się pisać sensowne komunikaty zatwierdzania przy każdym zatwierdzeniu, które mogą pomóc tobie i opiekunowi.

Jeśli pracujesz z innymi, komunikaty zatwierdzania są bardzo ważne, aby zobaczyć, co zrobili inni: sprawdzanie różnic dla każdego z nich to znacznie więcej pracy i możesz nie zrozumieć, dlaczego ktoś to zrobił. Jeśli pracujesz z innymi, a ktoś (być może nie ty) musi spojrzeć wstecz, na przykład, aby śledzić zmiany zachowań od poprzedniej wersji w nieoczekiwany sposób ... naprawdę utrudniasz życie, nie wykorzystując pomocnej wskazówki w zatwierdzeniu wiadomość.

Jeśli pracujesz sam ... nad projektem, który jest w większości zakodowany „tak jak jest” (na przykład pojedyncza prosta strona internetowa lub skrypt), mniej więcej widzę, skąd pochodzisz. Jeśli pracuję nad czymś takim, dbam tylko o datę / godzinę lub najnowsze zmiany podczas kontynuowania pracy nad czymś (musisz przywrócić, ale to ma znaczenie tylko podczas programowania, a nie po jego wdrożeniu). Kontrola wersji to tylko sposób tworzenia kopii zapasowych z kilkoma dodatkowymi zaletami - w pełni zgadzam się, że nie w pełni wykorzystuję system - ale w niektórych małych projektach może to nie być potrzebne.

Przychodzi mi do głowy, zanim Kontrola wersji jest wykorzystywana na dwa różne sposoby, jeden z dokumentowania zmian w projekcie, a drugi jako pomocna dłoń dla programistów w miejscu ... a te dwie są całkowicie różne od siebie. Komunikaty zatwierdzania są bardzo ważne z jednej strony, a z drugiej strony mogą być w większości bezużyteczne.

Coś brakuje. Tam musi być powodem do wykonywania popełnić w przeciwnym razie nie byłoby to robić.

Jedyne, co musisz zrobić w komentarzu, to podać powód w słowa, nawet jeśli tylko on wip: adding new state objects

Podobnie jak wiele innych, w wolnym czasie robię trochę kodowania i używam systemu kontroli wersji, aby śledzić zarówno mój rozwój, jak i zmiany. Ilość wolnego czasu, którą mam, różni się znacznie w poszczególnych tygodniach i miesiącach. Wiele razy zdarzyło się, że nie miałem czasu na pisanie kodu w projekcie przez wiele tygodni, a nawet miesięcy, a taki czas, jaki miałem, zwykle wahałby się od 10 minut (typowy dzień) do 40 minut (dobry dzień). Z pewnością nie są to świetne warunki - szczególnie w przypadku problemów z debugowaniem.

Konieczne było przechowywanie notatek, które się nie zgubiły i były łatwe do odzyskania. Pod koniec każdej sesji praca sesji zostanie poświęcona szczegółowym komunikatem. Mógłbym wtedy przejść do historii zatwierdzeń i śledzić mój postęp i proces myślowy. To pozwoliło mi wybrać miejsce, w którym byłem w zeszłym tygodniu lub w zeszłym miesiącu z najmniejszą ilością straconego cennego czasu.

Próbuję zilustrować to, że dobre wiadomości zatwierdzania pomagają Tobie (i każdemu, kto przyjdzie po Tobie) dowiedzieć się, co się stało, co się dzieje, dokąd wszystko idzie, a przede wszystkim dlaczego.

Pomyśl o tym logicznie przez minutę. Kiedy popełniasz, oznacza to, że coś zostało zrobione. Jeśli nie zostawisz żadnej wiadomości, skąd inni ludzie będą wiedzieć, co zostało zrobione?

Jeśli nie skomentujesz swoich zobowiązań, możesz ulec pokusie skomentowania zmiany w źródle. Z czasem może to zagracić źródło.

Komunikaty zatwierdzania to szybki sposób na sprawdzenie, co się dzieje podczas odprawy, i pomoże innym deweloperom w zespole, gdy będą chcieli wiedzieć, który aspekt kodu zmienił się w jakich wersjach (z różnych powodów).

W powiązanej notatce sugerowałbym określenie numeru sprawy modułu śledzenia błędów (mam nadzieję, że go używasz) w komunikacie zatwierdzenia, aby w przyszłości pomocne było łatwe śledzenie rzeczy.

Aby opiekun tego kodu 1 rok później wiedział, kogo ścigać za ten okropny kod. :)