Najlepsze nawyki kontroli wersji dla programisty solo?

36

Jestem jedynym programistą w swojej pracy i choć rozumiem korzyści płynące z VCS; Trudno mi trzymać się dobrych praktyk. W tej chwili używam git do tworzenia głównie aplikacji internetowych (które nigdy nie będą dostępne ze względu na moją pracę).

Mój obecny obieg pracy polega na wprowadzaniu wielu zmian w witrynie programistycznej, testowaniu, poprawianiu, testowaniu, byciu szczęśliwym i zatwierdzaniu zmian, a następnie wypychaniu zatwierdzenia na działającej stronie internetowej (więc jeśli pracuję nad dużą nową zmianą, mogę tylko zatwierdzaj raz w tygodniu, ale moje IDE ma dobrą historię cofania niezaangażowanych rzeczy).

Zasadniczo używam git tylko do przełączania się między komputerami (np. Pracuj komputer na komputer domowy lub komputer na żywo), ale w ciągu dnia tak naprawdę nie widzę korzyści. To prowadzi mnie do posiadania długich list zmian prania (i mam problem ze znalezieniem dobrego msg dla każdego zatwierdzenia; i zawsze, gdy się spieszę - zostawiam gówniane wiadomości, takie jak „różne zmiany w adminach i szablonach”).

Jak często powinienem się angażować? Czy każda zmiana jednowierszowa powinna otrzymać zatwierdzenie? Czy powinienem popełnić przed jakimkolwiek testem (np. Przynajmniej w przypadku błędów składniowych / kompilacyjnych, a następnie całkowicie go cofnąć; pomysł nie zadziałał lub wiadomość jest kłamstwem)?

Czy powinienem upewnić się, że zobowiązuję się każdego ranka / popołudnia, zanim przestanę pracować na obiad, gdy jest jeszcze świeży? Czego mi brakuje, mając złe nawyki związane z VCS?

dr jimbob
źródło
2
Być może jednym z powodów, dla których czujesz, że VCS nie działa dla Ciebie, ponieważ używasz Git jako programisty solo? Git wydaje mi się przesadą dla jednego programisty, być może coś prostszego z mniejszą liczbą funkcji, takich jak SVN, będzie łatwiejsze w użyciu?
wałek klonowy
6
@maple_shaft: Nie korzystałem z Git, ale Mercurial jest tak prosty jak Subversion dla podstawowych zadań deweloperskich solo. (Właściwie prostsze, ponieważ tworzenie ekwiwalentu repozytorium jest łatwiejsze.)
David Thornley,
15
Dlaczego git byłby przesadny?
Tamás Szelei,
1
@maple_shaft prawdziwa korzyść przychodzi później. Nie musisz zadowolić się mniejszym kosztem.
3
Warto wspomnieć, że w przypadku DVCS, takich jak git i mercurial, aby czerpać korzyści z zewnętrznej kopii zapasowej kontroli źródła (jak wspomniano w niektórych odpowiedziach), należy regularnie wypychać, a nie tylko zatwierdzać.
holowniki

Odpowiedzi:

24

Bardzo za tobą tęsknisz.

W pewnym sensie też jestem solo. Każdorazowo dokonuję znaczącej zmiany, lub zanim zacznę znaczącą, aby móc wrócić, jeśli coś spieprzę, i co jakiś czas, nawet jeśli nie robię nic wielkiego. Naprawdę nie codziennie, ale blisko. Czasem kilka razy dziennie.

Dostaję to, że mogę wrócić w dowolnym momencie. Co dużo Pomocne jest także zamówienie gałęzi.

Myślę, że to daje mi dużo porządku.

Używam svn i mam tego dość. Ale nie mogę poświęcić więcej czasu na naukę czegokolwiek innego.

Powodzenia.

cauchy
źródło
+1 Ostatnio sam zacząłem używać VCS, a GIT jest dla mnie rzeczą :)
yati sagade,
1
Długo unikałem kontroli wersji, ponieważ miałem wrażenie, że jest ona zbyt nieporęczna / brzydka / irytująca. Kilka miesięcy temu postanowiłem zapoznać się z Subversion i teraz przysięgam.
Dalin Seivewright,
1
Mam kilka solowych projektów: niektóre na Github, inne nie. Zawsze używam git, nawet jeśli tylko buduję coś do wyraźnych celów uczenia się konkretnego API / narzędzia. Wymusza dobre nawyki dla prawdziwych projektów, w których jest bardziej przydatny, jak opisuje @jbcolmenares.
sarumont,
2
Sprzeciwiam się Twojemu „nie mogę poświęcić więcej czasu na naukę czegokolwiek innego” na hginit.com . Policz czas spędzony na złości w svn przez tydzień, a następnie poświęć tyle czasu, aby przeczytać hginit w następnym tygodniu.
tdammers
@tdammers rzuci okiem
cauchy
18

Powinieneś często popełniać. Z pewnością powinieneś dokonać tego po osiągnięciu jakiegoś logicznego kamienia milowego. Jeśli zajmuje to więcej niż jeden dzień, powinieneś przynajmniej zobowiązać się pod koniec dnia pracy, lub jeszcze lepiej, podzielić pracę na mniejsze części.

Jest wiele powodów, aby to zrobić. Na przykład co się stanie, jeśli komputer ulegnie awarii? O wiele lepiej jest stracić tylko dzień pracy niż tydzień lub miesiąc. Innym powodem jest to, że częste zatwierdzenia ułatwiają izolację błędu. Możesz przeprowadzić wyszukiwanie binarne i dowiedzieć się, która niewielka zmiana spowodowała błąd.

Kolejna rzecz: zanim zatwierdzisz, powinieneś zrobić różnicę i spojrzeć na wszystkie dokonane zmiany. Pozwala to sprawdzić, czy wszystkie zmiany mają sens i czy niczego nie zapomniałeś. Pomaga to również wymyślić lepszy komunikat zatwierdzenia. I oczywiście jest to kolejny powód do częstego popełniania: o wiele łatwiej jest przejść dzień zmian niż miesiąc.

Dima
źródło
„co, jeśli komputer się zawiesi” - pliki są zapisywane na dysku dość często, a kopie zapasowe są tworzone co noc (jeśli chodziło o uszkodzenie dysku twardego). Przydaje się jednak +1 do binarnego wyszukiwania błędów. Jestem całkiem dobry w szybkim znajdowaniu 95% moich błędów; ale co jakiś czas pojawia się naprawdę dziwny błąd wynikający z pozornie nieistotnej zmiany w innej części programu.
dr jimbob
Tak mam na myśli „jeśli dysk się zepsuje”, „jeśli sufit się zapadnie” lub „jeśli w pobliżu wyłączy się urządzenie EMP”. :) Wszystko, co może spowodować utratę danych. Często zatwierdzanie jest najprostszym sposobem na utworzenie kopii zapasowej pracy i pozwala na łatwe tworzenie kopii zapasowych poza siedzibą, przy użyciu zdalnego serwera kontroli wersji.
Dima,
1
@Dima: musisz naciskać, a nie tylko zobowiązać się do posiadania kopii zapasowej
liberforce
@liberforce Nie wszystkie systemy kontroli wersji mają operacje wypychania. Ta odpowiedź pochodzi z 2012 roku. W tym czasie korzystałem z subversion, która nie jest rozpowszechniana. Więc nie pchaj.
Dima,
2
@Dima: jasne, ale OP używał git, więc instrukcje mogą wprowadzać w błąd, ponieważ nie mówiłeś, że mówisz o SVN.
liberforce
10

Aby jak najlepiej wykorzystać CVS, powinieneś pracować nad jedną funkcją / naprawą błędu naraz i zatwierdzić, kiedy ta funkcja / poprawka zostanie zakończona. Dzięki temu zyskasz:

  • komunikaty zatwierdzania będą łatwiejsze do utworzenia i będą miały większy sens;
  • łatwiejsze śledzenie przyszłych błędów z powrotem do zmian, które je wprowadziły;
  • łatwiejsze przywracanie do poprzedniego stanu (nawet jeśli oznacza to utratę nieudanej funkcji, ale utrzymanie poprawek błędów, które wystąpiły później).

Ponadto, ponieważ przełączasz się między komputerami PC, powinieneś mieć co najmniej dwie gałęzie:

  • gałąź „Gotowy do pracy”, która zawsze działa (oprócz błędów, nad którymi pracujesz, oczywiście w gałęzi programistycznej)
  • gałąź rozwoju, która może być od czasu do czasu nie do uruchomienia (np. podczas podróży do domu z pracy;).
Ethan Furman
źródło
1
+1 za gotowy oddział! Nie wiem, ile razy jestem proszony o pokazanie oprogramowania, gdy przechodzą szef i potencjalni klienci. Fajnie jest mieć wersję, która faktycznie działa, a nie w stanie płynności.
bluebill
Wersja, która działa i jest testowana, zwykle jest oznaczona. To powinieneś pokazać, chyba że szef chce zobaczyć najnowsze zmiany. W takim przypadku wystarczy git stashpokazać i pokazać, co masz, lub sprawdzić konkretny zatwierdzenie. Oczywiście, jeśli masz duże zmiany, które są w toku, powinny one znajdować się w osobnej gałęzi w toku, więc twoja gałąź master jest de facto stabilna.
liberforce
7

Czy każda zmiana jednowierszowa powinna otrzymać zatwierdzenie?

Jeśli to naprawia błąd, na pewno.

Czego mi brakuje, mając złe nawyki związane z VCS?

Pracowałem z facetem, który miał „złe nawyki VCS”. Uwielbiał pracować sam i był odpowiedzialny za linię produktów, która przyniosła około 1 000 000 $ rocznie. Popełniałby tylko wtedy, gdy szef go dręczył. Pewnego dnia jego twardy dysk się zawiesił. Po przygotowaniu zastępstwa dla niego odkryliśmy, że jego ostatnie zameldowanie miało miejsce 6 miesięcy wcześniej. Ponieważ VCS był bezpieczny dla źródła, możesz zgadnąć, co jeszcze poszło nie tak - ostatnie zatwierdzenie zostało uszkodzone. Musieliśmy cofnąć się o ponad rok, aby uzyskać nieuszkodzoną wersję jego linii produktów. Nie został zwolniony, chociaż powinien.

Kolejna anegdota dotyczy mnie. Kiedyś przechowywałem kod dla projektów hobbystycznych i badawczych na wymiennych dyskach twardych. Pewnego dnia włamano się do mojego mieszkania. Laptop (który został uszkodzony) i wszystkie wymienne dyski twarde zostały skradzione. Każde DVD (z wyjątkiem Red Dawn) zostało skradzione. Żaden z komputerów stacjonarnych nie został skradziony. Gdybym miał kontrolę źródła poza siedzibą, nie straciłbym 15 lat projektów, zwłaszcza że niektóre były oparte na projektach akademickich - wielu profesorów opuściło środowisko akademickie, aby przejść do prywatnego przemysłu, więc projekty te zniknęły w korporacyjnej czarnej dziurze IP, tworząc utracony kod niemożliwy do odzyskania.

Jak często powinienem się angażować?

Podzielę to na kilka wskaźników:

  • Ile pracy chcesz stracić, jeśli komputer umrze? czy zostanie skradziony?

  • Jeśli to naprawia Bug_1234, sprawdź kod z komentarzem „naprawia Bug_1234”.

  • Jeśli jest to logiczna dostawa / kamień milowy, należy to zgłosić za pomocą komentarza w rodzaju „Bug_1234, form_xyz” (lub Task_1234 odpowiednio).

  • Zawsze sprawdź kod w piątek wieczorem, zanim pójdziesz do domu. Zrób też odprawę (lub cofnij kasy) wszystkiego przed wyjazdem na wakacje.

  • Ilekroć wymaga tego polityka firmy.

Tangurena
źródło
1
Zgadzam się, że facet powinien zostać zwolniony. Szaleństwo nie pociąga za sobą, nawet w przypadku wydawnictw. Jak znaleźć błędy, które pojawiły się w wersji 1.2, jeśli nie wiesz, jaki kod znajduje się w wersji 1.2? Czy ten facet po prostu kopiował kod i zipował na swoim twardym dysku?
liberforce
5

Nie myśl w kategoriach liczby zmian linii. Pomyśl o kawałkach funkcjonalności. VCS pozwala na umieszczenie nagłówka w centralnym miejscu dla każdej porcji funkcjonalności, dzięki czemu można łatwo zobaczyć „to, co się tu wydarzyło”, np. Z git log.

Również IDE, takie jak Eclipse, pozwalają wskazać daną linię i przejść do zatwierdzenia, które nadało jej kształt, który widzisz. Innymi słowy, możesz przejść bezpośrednio z linii źródłowej do zatwierdzenia. Jeśli zatwierdzenie jest małe i ma dobrą wiadomość, jest o wiele bardziej pomocne niż „naprawione mnóstwo błędów”.


źródło
4

Powiedziałbym, że największą rzeczą, za którą tęsknisz, grupując zmiany w ten sposób, jest możliwość śledzenia, kiedy i gdzie wprowadzono błędy.

Z mojego doświadczenia wynika, że ​​kilka razy zauważono jakiś błąd dwa-trzy tygodnie po jego wprowadzeniu, a konieczność przesiewania tygodniowych zatwierdzeń jest trudna tak długo po tym fakcie. W takich przypadkach pomocne było po prostu wyszukiwanie binarne za pomocą commits, aby ustalić, która zmiana spowodowała problem. Te błędy to głównie błędy wykorzystania pamięci w kodzie C ++, więc może nie zdarzać się tak często w twoim projekcie.

Inne korzyści wchodzą w grę podczas tworzenia zespołu - proste komentarze zatwierdzania, łatwiejsze łączenie, powiązanie zatwierdzeń z poprawkami błędów itp.

Sądzę, że w twoim przepływie pracy, jeśli zaczniesz zatwierdzać codziennie lub co pół dnia, będziesz musiał użyć tagów lub zakładek, aby śledzić, która wersja kodu jest używana w aktywnej witrynie. Powiedziałbym, że to najważniejsza rzecz do zapamiętania.

holowniki
źródło
4

Jestem również programistą solo, używam SVN i uwielbiam to. Napisałem nawet narzędzie do konwersji struktury mojej bazy danych i zawartych w niej danych testowych do formatu xml, dzięki czemu mogę uwzględnić to w kontroli źródła.

Zwykle zobowiązuję się, ilekroć wykonam autonomiczną jednostkę pracy. Czasami, jeśli wykonam kilka trywialnych i niezwiązanych poprawek jednowierszowych tu i tam, wówczas zatwierdzam je wszystkie razem, ale jeśli zdarzy się poprawka jednowierszowa między dwiema niepowiązanymi dużymi autonomicznymi jednostkami pracy, wówczas otrzyma swoją własną popełnić, nie ma w tym nic złego.

Ponadto zawsze zatwierdzam kod, który się kompiluje i prawie zawsze kod, który również przechodzi wszystkie podstawowe testy. Jeśli nie, upewnij się, że w komunikacie zatwierdzenia znajduje się komunikat „NIE DZIAŁA”. Jedynym przypadkiem, kiedy to się dzieje, jest dokonanie ważnych zmian, których nie chcę stracić, nawet jeśli jeszcze nie działają, a na dodatek zamierzam rozpocząć wielką refaktoryzacyjną przygodę, której nie jestem pewien, czy odniesie sukces. Tak więc używam repozytorium jako kopii zapasowej pracy, którą wykonałem do tej pory, zanim zaryzykuję zepsucie go i wyrzucenie.

Oznacza to, że zawsze zatwierdzam, gdy mój kod źródłowy musi zostać zatwierdzony; absolutnie nie ma sensu wprowadzać reguł zatwierdzania rano lub wieczorem. Jest to stan, w którym kod określa, czy nadszedł czas na zatwierdzenie.

Wiadomości umieszczone w repozytorium nie mają większego znaczenia. Jeśli absolutnie nie możesz wymyślić czegoś sensownego, nadal lepiej jest zatwierdzić pustą wiadomość, niż wcale nie zatwierdzać, kiedy powinieneś.

Jeśli nie możesz wymyślić dobrej wiadomości zatwierdzenia, ponieważ wszystko, co wymyślisz, brzmi głupio, pamiętaj, że to jest w porządku; Oczekuje się, że komunikaty zatwierdzania będą zawierały oczywiste, więc będą musiały wydawać się głupie, gdy je piszesz. Ale zaufaj mi, jeśli miesiąc później będziesz musiał sprawdzić stare wersje, będziesz wdzięczny nawet za te głupie wiadomości za brak wiadomości.

Mike Nakis
źródło
1

Zatwierdź za każdym razem, gdy wykonasz „logiczną” zmianę. Na przykład, jeśli wdrażasz nową funkcję, robisz to krok po kroku. Każdy z tych kroków zwykle zależy od siebie. Możesz więc po prostu zatwierdzić te kroki osobno i wyjaśnić w komunikacie zatwierdzenia, dlaczego każdy krok jest wymagany.

Komunikat zatwierdzenia jest naprawdę ważny. Musisz unikać mówienia o tym , co robisz, mów, dlaczego to robisz. Kod już dokumentuje zmiany, ale za 6 miesięcy z przyjemnością zobaczysz, dlaczego je wprowadziłeś.

Jest to również przydatne, jeśli przypadkiem ktoś wskoczy i nie jesteś już sam. Nawet dla Ciebie czysta historia ułatwia korzystanie z informacji git blameo tym, kiedy i dlaczego zmieniono wiersz z błędem.

Dokonywanie małych zmian zamiast dużych zmian w błocie pozwala również przetestować stan pośredni. Możesz ukryć zmiany, jeśli musisz coś szybko zwolnić. Jeśli wprowadzisz błąd podczas jego wcześniejszego działania, możesz ukryć i sprawdzić, czy to twoje niezatwierdzone zmiany wprowadzają błąd, czy też było to w starszym zatwierdzeniu.

Możesz także uwolnić moc git bissect, która powie ci, że ten paskudny błąd. Jeśli zatwierdzenie ma 2000 linii, nadal pomaga, ale nie aż tak bardzo ...

Kolejną rzeczą jest to, że jest to pierwszy krok do ciągłej integracji (CI), a następnie ciągłego wdrażania (CD). CI i twoje testy mogą być uruchamiane przy nowym zatwierdzeniu, dlatego informują cię za każdym razem, gdy naciskasz zmiany, jeśli coś zepsują lub nie. W ten sposób możesz dowiedzieć się, czy wdrożenie jest bezpieczne, i zostać o tym powiadomiony w momencie pojawienia się problemu, a nie tylko przed zwolnieniem, gdy jesteś w pośpiechu.

O twoich pozostałych pytaniach:

  • nie popełniaj rzeczy, których nawet nie skompilowałeś, chyba że zechcesz przepisać swoją historię w tym celu (używając git rebase --interactive).
  • zmiana w jednym wierszu zasługuje na zatwierdzenie, jeśli ma ona odrębny cel (naprawia błąd lub nie jest związana z aktualnie niezatwierdzonymi zmianami). Użyj, git add --patchaby je wystawić.
  • nie musisz zmuszać się do popełnienia przed obiadem, chyba że masz ważne rzeczy, których nie możesz stracić. W takim przypadku możesz zlecić pracę w oddzielnym oddziale.
  • zatwierdzanie i przekazywanie do zdalnego repozytorium jest kopią zapasową. Jeśli popełnisz błąd i popchniesz tylko raz w tygodniu, w najgorszym przypadku możesz stracić tydzień pracy.
liberforce
źródło
0

Jak często powinienem się angażować?

Jako solowy programista zazwyczaj zobowiązuję się za każdym razem, gdy czuję, że dokonałem znaczącej zmiany, po podstawowych testach i kiedy kończę projekt pod koniec nocy.

Czy każda zmiana jednowierszowa powinna otrzymać zatwierdzenie?

Nie, chyba że ta zmiana w jednej linii znacząco zmieni funkcję lub błąd.

Czy powinienem popełnić przed jakimkolwiek testem (np. Przynajmniej w przypadku błędów składniowych / kompilacyjnych, a następnie całkowicie go cofnąć; pomysł nie zadziałał lub wiadomość jest kłamstwem)?

Prawdopodobnie nie. Przynajmniej dla mnie większość testów i kodowania wykonuję na „kopii roboczej” i zatwierdzam po tym, jak jestem zadowolony ze swoich zmian. W wielu IDE pokaże mi, co się zmieniło przed dokonaniem zatwierdzenia i da mi możliwość dołączenia notatek do zatwierdzenia

Czy powinienem upewnić się, że zobowiązuję się każdego ranka / popołudnia, zanim przestanę pracować na obiad, gdy jest jeszcze świeży? Czego mi brakuje, mając złe nawyki związane z VCS?

Nie znam się zbyt dobrze na VCS ani na tym, jakie to powoduje złe nawyki. Myślę, że w większości podzieliłem się moją opinią w odpowiedzi na pierwsze pytanie.

W odpowiedzi na postawione ogólne pytanie wydaje się, że najczęściej używasz zatwierdzeń jako gałęzi, które są omówione w innym poście z odpowiedziami. Nie jestem pewien, którego IDE używasz, który ma dobrą historię cofania itp., Ale nie znalazłem takiego, który moim zdaniem byłby dobry poza ponownym uruchomieniem IDE i przemieszczaniem się między komputerami.

dbuell
źródło
I am not very familiar with VCS or what bad habits it causes.Szczęściarz!
yannis
1
Nie jestem pewien, w jaki sposób czytałem to niepoprawnie wiele razy, ale nadal czytałem to jako „VSS” jak w bezpiecznym źródle Visual. Jestem dość zaznajomiony z różnymi systemami kontroli wersji, w tym SVN i GIT, i często używam ich jako programistów solo, ale prawdopodobnie mam kilka złych nawyków, biorąc pod uwagę, że tak naprawdę nie korzystałem z nich w kontekście dużego scenariusza z wieloma programistami .
dbuell
Cóż, ponieważ walczę z SourceSafe od ponad 3 lat, mój komentarz nadal brzmi: Na szczęście! Na przykład, VSS6 może obsługiwać repozytoria o wielkości około 200mb - 300mb, a następnie, jeśli będziesz miał szczęście, kilka plików zostanie losowo uszkodzonych. Oczywiście tam, gdzie wiele poprawek i obejść, a VSS nigdy nie było zamierzone przez MS na pełnowartościowe vcs, ale
uważaj
0

Jestem zwykłym komisarzem i uważam, że mi to odpowiada, ale co prawda moje komunikaty o zatwierdzeniach są prawie zawsze takie,

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

Nie mogę więc dokładnie powiedzieć, że dokonywanie tak częstych i nawykowych zobowiązań w moim oddziale (merkurialne) dokładnie zachęca do najbardziej szczegółowych dzienników zatwierdzeń. Czasami nawet popełniam kod zrobiony w połowie, jeśli powiedzmy, że moja żona prosi mnie, żebym poszedł na obiad, w którym to momencie po prostu pospiesznie skopiuję i użyję poprzedniego komunikatu „Praca nad [...]”.

Moje wzorce protokołów zatwierdzania są zwykle takie, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

Z drugiej strony jednak uratował mi tyłek. Czasami wpadam na przypadek, którego nie przewidywałem i nie testowałem, w którym to momencie częste zatwierdzenia pomagają mi zorientować się, gdzie dokładnie popełniłem błąd.

Więc nie wiem o najlepszych nawykach i na pewno nie jestem kimś, kto słucha idealnych nawyków rejestrowania zmian, ale z pewnością mogę powiedzieć, że częstsze zatwierdzanie może zdecydowanie pomóc, gdy trzeba wykonać regresję.

Czy każda zmiana jednowierszowa powinna otrzymać zatwierdzenie?

Popełniłem wcześniej zmiany w jednej linii, ale zwykle były to trudne i być może zabrakło mi czasu. Moje zobowiązania nie zawsze przypominają idealne i kompletne jednostki pracy lub zmiany. Jak już powiedziano, czasami są one wynikiem tego, że moja żona poprosiła mnie, żebym niespodziewanie wyszedł na obiad.

TBH, wiele moich zobowiązań, które wynikają z tego "Working on [...]"logu, nie modelują spójnych jednostek zmian (dlaczego często nie mogę wymyślić lepszego komunikatu "Working on [...]"), ale po prostu wynik mojego wzięcia oddechu, jak zrobienie sobie filiżanki kawy. "Completed [...]"Wiadomość oznacza koniec tej jednostce pracy, a tam często piszą dużo bardziej szczegółowy komunikat wraz z pierwszych "Started working on [...]"komunikatów typu, jeśli po prostu zacząć pracować nad czymś. Jeśli uśredniasz zatwierdzenia jak raz na 15 minut, wtedy wiadomości „Praca nad [...]” są bardziej jak pośrednie dla tego, co ktoś może zatwierdzić w jednym obszerniejszym zatwierdzeniu z bardziej szczegółowym komunikatem.

Czy powinienem popełnić przed jakimkolwiek testem (np. Przynajmniej w przypadku błędów składniowych / kompilacyjnych, a następnie całkowicie go cofnąć; pomysł nie zadziałał lub wiadomość jest kłamstwem)?

Po prostu kontynuuję i zatwierdzam to przed czasem nawet przeprowadzeniem testów (ponownie, gdybym miał nieoczekiwane zdarzenie). Ponadto, mimo że jestem solo, pcham na serwer (tylko ten działający tutaj w domu w sieci LAN), który obsługuje CI. To może wydawać się przesadą, ale nie wiem, przyzwyczaiłem się do tego w moich poprzednich miejscach pracy. Poza tym nie chcę, aby za każdym razem ręcznie przeprowadzałem wszystkie testy jednostki i integracji. Lubię mieć to wszystko związane z pchaniem. Jeśli test się nie powiedzie, łatwo jest pracować w sposób postępowy, w którym wykonuję regresję, poprawiam błąd w najnowszej wersji i kontynuuję. To powiedziawszy, przynajmniej buduję kod w oparciu o kompilację debugowania przed zatwierdzeniem.

Czy powinienem upewnić się, że zobowiązuję się każdego ranka / popołudnia, zanim przestanę pracować na obiad, gdy jest jeszcze świeży?

Lubię robić, zanim wyjdę i mam przerwę między programowaniem. Nie zastanawiałem się nad tym, dlaczego dokładnie, dopóki nie spotkałem się z tym pytaniem. Podejrzewam, że ma to uniemożliwić sobie wzięcie tego, gdzie skończyłem bez dziennika zmian w miejscu, w którym skończyłem, że mogę się różnić i tak dalej. Hmm, muszę do ciebie wrócić, ponieważ może nie jest to teoretycznie potrzebne, biorąc pod uwagę, jak często popełniam. Nadal czuję się bardziej komfortowo, popychając i pchając, zanim wyjdę z komputera z jakiegokolwiek powodu. Niektóre z nich mogą być dawnym lękiem psychologicznym, powiedzmy, komputer płonął po moim odejściu i miałam kierowników projektów w czasach, gdy korzystaliśmy z SVN, a deweloperzy czasami pracowali tygodniami, nie robiąc oddechu i stale przypominając nam, aby sprawdzać kod tak często, jak to możliwe, przypominając nam, że nasz kod jest własnością firmy. Jest to również trochę bardziej wydajne, szczególnie w przypadku wypychania, dzięki czemu mój proces CI może rozpocząć wykonywanie wszystkich testów, gdy mnie nie ma, abym mógł wrócić i zobaczyć wyniki.

Aha, a czasem się upijam po odejściu i zwykle jest to zły pomysł, aby pisać skomplikowany kod po pijanemu (choć nie zawsze; pewnego razu wymyśliłem naprawdę fajny system menu kontekstowego po tym, jak byłem pijany przez eurekę, ale miałem tylko 6 piw i kodowanie nie było tak skomplikowane). Jeśli spróbuję to zrobić, przynajmniej popełniłem trzeźwo napisany kod, zanim odszedłem, aby powrócić do zamiast mieszania pijanego kodu z trzeźwym kodem, w którym to momencie mój dziennik zatwierdzeń może odczytać, "Reverting back to code written before Jagermeister shots."nie robię tego bardzo często, chyba że dostałem inspirację od pijanego kodu, ale w tych rzadkich przypadkach naprawdę pomogło mi, że popełniłem coś, zanim wyszedłem i upiłem się.


źródło
Ogólna zasada: jeśli masz dwa kolejne zatwierdzenia z identycznymi wiadomościami, prawie na pewno robisz to źle. Albo powinny być jednym zatwierdzeniem, albo powinieneś dowiedzieć się, co ich różni i napisać logi odzwierciedlające tę różnicę (np. „Zdefiniuj nowe dane malowania” i „ustaw poprawnie dane malowania” zamiast „pracując w systemie malowania” x2).
Marnen Laibow-Koser