Kiedy zatwierdzić kod?

59

Podczas pracy nad projektem kod może zostać opracowany dość szybko w ciągu jednego dnia lub kawałek po kawałku przez dłuższy okres kilku tygodni / miesięcy / lat. Ponieważ zatwierdzenia kodu stają się uważane za miarę rozwoju projektu, tak naprawdę nie oznacza to, że napisano więcej kodu niż projekt o mniejszej liczbie zatwierdzeń.

Pytanie brzmi, kiedy naprawdę dokonać zatwierdzenia w repozytorium, aby zatwierdzenie było uzasadnione?

Jako dodatek: Czy poprawną praktyką jest mierzenie rozwoju projektu na podstawie jego zobowiązań?

komar
źródło
9
Większość rzeczy, które można łatwo obliczyć, to złe wskaźniki, ponieważ są one nadmiernie uproszczone lub można je łatwo rozegrać, aby uzyskać dobre wyniki w porównaniu z konkretnym pomiarem.
unholysampler
Dziękuję wszystkim za wkład. Istnieje wiele ważnych powodów, aby dokonać zatwierdzenia, które jest rozłożone na odpowiedzi, i nie mogę zaakceptować wielu odpowiedzi, akceptuję odpowiedź z największą liczbą głosów do tej pory. Ale przyjmuję wszystkie twoje odpowiedzi.

Odpowiedzi:

79

Zobowiązujesz się, gdy osiągniesz stan bazy kodu, który chcesz zapamiętać. Istnieje wiele powodów, dla których możesz chcieć zapamiętać konkretny stan bazy kodu, więc nie może być żadnych sztywnych reguł określających, kiedy dokonać zatwierdzenia. Jednak liczba zatwierdzeń zdecydowanie nie jest miarą jakości ani postępu.

Neil Butterworth
źródło
10
Zgadzam się z dodatkiem, że bagażnik to inna historia. Na przykład, aby sprawdzić w bagażniku mojego zespołu, musi on: a) poprawnie zbudować ib) coś ukończyć. Każdy członek zespołu może jednak utworzyć gałąź i może znajdować się w dowolnym stanie, w jakim chcą.
Edward Strange
34

W tym kontekście lubię myśleć o kodowaniu jako o wspinaczce skalnej. Wspinasz się trochę, a następnie umieszczasz kotwicę w skale. Jeśli kiedykolwiek upadniesz, ostatnią posadzoną przez ciebie kotwicą jest punkt, który cię zabezpiecza, więc nigdy nie spadniesz z odległości większej niż kilka metrów. To samo z kontrolą źródła; trochę kodujesz, a kiedy osiągniesz nieco stabilną pozycję, popełniasz poprawkę. Jeśli okropnie zawiedziesz, zawsze możesz wrócić do ostatniej wersji i wiesz, że jest stabilna.

To powiedziawszy, jeśli pracujesz w zespole, zwykle upewniasz się, że wszystko, co popełniasz, jest kompletne, ma sens, buduje się czysto i nie niszczy rzeczy innych. Jeśli chcesz wprowadzić większe zmiany, które mogą zakłócać pracę innych ludzi, stwórz oddział, abyś mógł dokonywać zmian bez przeszkadzania innym.

Zależy to również od używanego systemu SCM. Systemy rozproszone zazwyczaj sprawiają, że scalanie i rozwidlanie jest bezbolesne i szybkie, a można zatwierdzać lokalnie; oznacza to, że powinieneś dużo popełnić i pchnąć / scalić, kiedy wykonałeś znaczną ilość pracy. W przypadku scentralizowanych systemów, takich jak svn lub cvs, zatwierdzanie jest bardziej kosztowne i wpływa na wszystkich. Rozgałęzienie częściowo rozwiązuje ten problem, ale ponieważ dzieje się to na serwerze, może być boleśnie powolne, a scalanie może być kłopotliwe. Dlatego w scentralizowanych SCM często zachowuje się bardziej ostrożną kulturę, w której dokonuje się zobowiązania dopiero po wykonaniu znacznej ilości pracy.

Jeśli chodzi o dodatek: Proszę, nie rób tego. Linie kodu, liczba zatwierdzeń, liczba znalezionych / rozwiązanych błędów itp. Są bardzo złymi pomiarami jakości, a nawet ilości.

tdammers
źródło
Zakładam, że to samo dotyczy nowych oddziałów, w których cały nowy rozwój jest zlecany twojemu oddziałowi, który następnie przekażesz, gdy funkcja będzie gotowa? To znaczy. możesz przekazać nawet dużo niekompletnego kodu do swojego prywatnego oddziału.
Juha Untinen 27.04.16
Tak, ale w mniejszym stopniu, ponieważ (patrz oryginalna odpowiedź) nikomu nie przeszkadzasz bezpośrednio. W zależności od SCM, o którym mowa, zwykle dobrą praktyką jest oczyszczenie historii zatwierdzeń przed połączeniem w górę (np git rebase -i.).
tdammers
13

Jeśli korzystasz z DVCS, takich jak Mercurial lub Git, powinieneś zobowiązać się do lokalnego repozytorium, ilekroć wykonasz znaczną ilość pracy. Pchaj go jednak do współużytkowanego repozytorium tylko wtedy, gdy działa, samodzielna zmiana, która została przetestowana.

W przypadku nie dystrybuowanego VCS (jak np. SVN) stosuje się tę samą logikę, zamiast lokalnego repozytorium użyj gałęzi prywatnej zamiast push - scal do gałęzi głównej.

vartec
źródło
+1 Dziwię się, że nie było więcej głosowania. To była moja pierwsza myśl - dvcs lub vcs
Michael Durrant
9

Powinieneś popełniać wcześnie i często.

Znam ludzi, którzy popełniają tak często, jak co 90 sekund. Poważnie. Wydaje się, że działa dla nich. Eksperymentowałem z zatwierdzaniem za każdym razem, gdy zapisuję plik, co jest prawdopodobnie częściej niż 90 sekund. Dzisiaj prawdopodobnie popełniam co 15 minut. VCS, który pozwala zgnieść wiele zatwierdzeń w jeden i który pozwala na zatwierdzenie lokalne (np. Git), czyni to o wiele łatwiejszym.

Jak często powinieneś robić? Trudno powiedzieć, ale prawdopodobnie częściej niż teraz. Kontynuuj zaangażowanie coraz częściej, znajdź punkt, który wydaje się absurdalnie zbyt często, a następnie trochę się wycofaj. Są szanse, że skończysz z czymś rozsądnym.

Mierzysz rozwój produktu na podstawie wartości dostarczanej jego użytkownikom. Nie ma innego dokładnego pomiaru.

Rein Henrichs
źródło
1
+1. Kiedy połączysz BDD-As-If-You-Mean-It, Refactor Till You Drop, Atomic Coding i wysoce ekspresyjny język, 90 sekund może upłynąć dużo czasu bez zatwierdzenia.
Jörg W Mittag
8

Zatwierdzenia są elementami składowymi dowolnych danych / kodu kontrolowanych wersjami. Każde zatwierdzenie powinno wykonać dokładnie jedną z następujących czynności:

  • Dodaj nowy fragment danych lub funkcji
  • Napraw jeden lub więcej błędów (jeden zatwierdzenie dla każdej poprawki, jeśli to możliwe), gdzie poprawka może być:
    • Poprawa wydajności
    • Korygowanie nieprawidłowego działania kodu
    • Usuwanie błędów typograficznych
  • Refaktoryzacja kodu lub danych bez zmiany semantyki. To zawiera:
    • Przepisywanie kodu, który zachowuje się identycznie jak oryginał
    • Zmiana reprezentacji danych na inny format
    • Formatowanie kodu lub danych w celu spełnienia wytycznych formatowania projektu
  • Scal zmiany z innego oddziału (albo w górę / w dół)

Również podczas pracy w oddziałach zatwierdzenia muszą przejść do gałęzi, która jest bardziej trafna. Dwa zatwierdzenia nie powinny mieć tego samego komunikatu zatwierdzenia (implikującego podobne zmiany), ale w różnych gałęziach, ponieważ dezorientują współpracowników. Lepszym sposobem jest zatwierdzenie głównej gałęzi i połączenie z gałęzią funkcji.

Jeśli osoby zatwierdzające przestrzegają powyższej zasady, trywialne staje się:

  • Cofnij określoną zmianę bez żadnych skutków ubocznych
  • Zidentyfikuj zachowanie zmieniające kod na podstawie zmian formatowania kodu
  • Łączenie różnych gałęzi, unikając większości konfliktów
  • Współpracuj z innymi programistami, którzy mogą łatwo wprowadzić zmiany

Jeśli chodzi o pomiar postępów projektu w oparciu o zatwierdzenia, możliwe jest, że nie zostaną wzięte pod uwagę zmiany w refaktoryzacji i zmiany w usuwaniu błędów.

justjkk
źródło
Myślę, że ta odpowiedź musi być zaakceptowaną odpowiedzią, ale prawdopodobnie pytający szukał prostszego wyjaśnienia :)
Behnam Rasooli
7

Zatwierdź tylko wtedy, gdy jednostka pomyślnie przetestowała daną funkcję / moduł / funkcjonalność i masz wystarczającą pewność, że jest ona gotowa do integracji lub testowania systemu.

I aby odpowiedzieć na dodatkowe pytania - NIE !! miarą tego, gdzie projekt jest, nigdy nie powinna określać liczba zatwierdzeń ... kto wie, co faktycznie zostało popełnione? Czy został pomyślnie przetestowany w systemie, a nawet w jednostce. Tylko dlatego, że jest zaangażowany - to nie znaczy, że jest gotowy do produkcji.

Catchops
źródło
5
Byłoby to prawdą, gdybyś zobowiązał się do linii głównej, ale jeśli byłeś zaangażowany w gałąź funkcji lub gałąź prywatną, nie ma potrzeby, aby była gotowa do integracji.
Neil Butterworth,
1
@Neil Butterworth: ... chyba że w tym samym oddziale pracują inni programiści z pewnymi zależnościami od kodu.
FrustratedWithFormsDesigner
@Frustrated W takim przypadku z pewnością powinien być kompatybilny, ale nie sądzę, że powinien być gotowy do integracji i testowania systemu.
Neil Butterworth,
1
Interesująca dychotomia tutaj między rozproszonymi a scentralizowanymi vcs. Z rozproszonymi vcs nigdy nie będzie to problemem, ponieważ możesz zobowiązać się do lokalnego przedstawiania gałęzi i trzymać z dala od innych programistów.
George Mauer
2
@George - To jest fałszywa dychotomia. Prawdziwa dychotomia polega na wykorzystaniu prywatnych (na dewelopera) oddziałów lub publicznych (udostępnionych przez kilku programistów). Jest to ortogonalne w stosunku do tego, czy korzystasz ze scentralizowanego rozproszonego VCS (jednak DVCS zachęcają prywatne oddziały, ponieważ gałęzie zaczynają się jako prywatne, dopóki ich nie opublikujesz).
Stephen C. Steel
6

Jako dodatek: Czy poprawną praktyką jest mierzenie rozwoju projektu na podstawie jego zobowiązań?

Nie. Codziennie nadawano WTF, dlaczego jest to okropny pomysł.

Moją ogólną zasadą przy zatwierdzaniu kodu jest meldowanie się po ukończeniu fragmentu kodu i jego kompilacji. Chunk nie jest tak naprawdę zdefiniowany. Jeśli jest to małe zadanie, mogę się nie zameldować, dopóki nie skończę. Jeśli jest większy, mogę się zameldować po zakończeniu każdej części logicznej.

Ale nigdy nie sprawdzaj, czy się nie kompiluje. Wiem, że to głupie mówienie na głos, ale wcześniej musiałem to tłumaczyć ludziom.

Tyanna
źródło
1
+1 za ostrzeżenie o kompilacji. W biurze mieliśmy skarbonkę, w której każdy musiał wnieść opłatę za każdym razem, gdy popełnił coś, co spowodowało niepowodzenie kompilacji. Niestety dostaliśmy w ten sposób sporo pieniędzy, przynajmniej początkowo :)
Ray
@Ray - na moim ostatnim miejscu grzywna trafiła do funduszu lotto. Niestety, nigdy nie wytrąciło nas to z tego złego nawyku. : P
Tyanna
1

Dokonaj zatwierdzenia, gdy kod jest gotowy do współdzielenia z innymi użytkownikami kodu - gdy jest on względnie stabilny, bezpieczny i odpowiednio przetestowany.

I nie, nie sądzę, by zatwierdzenia były świetną miarą rozwoju projektu, ponieważ znam niektórych programistów, którzy dokonają każdej małej i drobnej zmiany, a inni, którzy dokonają tylko ogromnych poważnych zmian w funkcjonalności. Jak mierzysz ilościowo wartość jednego zatwierdzenia nad drugim?

FrustratedWithFormsDesigner
źródło
Pamiętaj, że w systemach rozproszonych commit! = Share. Powinieneś naciskać, gdy masz coś gotowego do udostępnienia.
Rein Henrichs
@ Rein Henrichs: Dobra uwaga, chociaż kontrola źródła tutaj w pracy nie ma tej funkcjonalności (przynajmniej o ile mi wiadomo). Kiedy coś jest popełnione, wszyscy inni w projekcie mogą zobaczyć i ponownie zsynchronizować (i zazwyczaj robią to, czasem na ślepo).
FrustratedWithFormsDesigner
Co może wskazywać, że możesz skorzystać z lepszych narzędzi. Wszystko, co zapobiega częstym popełnianiom, jest niepotrzebną przeszkodą.
Rein Henrichs,
@ Rein Henrichs: Nie będę się z tym kłócił !!
FrustratedWithFormsDesigner
1

Jak tylko odpowiednie zadanie zostanie wykonane . Zadaniem jest częścią historii użytkownika .

Zadanie zostało wykonane , gdy:

  • odpowiednie testy jednostkowe są zaliczone,
  • kod jest odpowiednio udokumentowany i
  • kod jest zatwierdzony.

Możesz mieć inną definicję zrobione .

Nie widzę wartości w pomiarze liczby zatwierdzeń. Jeśli jednak widzisz kogoś pracującego przez długi czas nad tą samą historią użytkownika (lub, co gorsza, historiami), jest to zapach.


źródło
1

Zatwierdź każdą znaczącą zmianę, która według ciebie nie psuje niczego. Jedyne, czego nie powinieneś robić, to zmiany stylu, ponieważ nie zawierają one zmiany w logice. Ale w przeciwnym razie im mniejsze zmiany, tym lepiej.

Im mniejsze zatwierdzenia, tym bardziej szczegółowe możesz udokumentować proces myślowy, który jest jednym z aspektów dobrego dziennika zatwierdzeń. Dobry przegląd kodu powinien dotyczyć nie tylko wyniku kodu, ale również procesu przemyślenia.

Ponadto posiadanie wielu małych zatwierdzeń ułatwia dzielenie na dwie części, o wiele za mało używaną funkcję kontroli wersji, która pozwoliła mi zaoszczędzić wiele godzin na szukaniu błędów igłowych w bazach kodu stogu siana.

Krótko mówiąc, przecinając; Odkryj problem w bieżącej bazie kodu. Następnie wybierz zatwierdzenie w dzienniku zmian, w którym masz pewność, że konkretny problem nie istniał. Zacznij od sprawdzenia zatwierdzenia w środku między wersją „dobrą” i „złą”. Sprawdź, czy problem nadal występuje. Jeśli tak, musisz spojrzeć wstecz, na środek „dobrego” i wcześniej przetestowanego zatwierdzenia. Jeśli problem zniknął, został wprowadzony po tej konkretnej zmianie, więc musisz sprawdzić środek między „złym” a wcześniej przetestowanym zatwierdzeniem. Powtarzać. Ostatecznie skończysz z zatwierdzeniem, które wprowadziło problem. Ale tylko jeśli masz małe zobowiązania, w przeciwnym razie będziesz po prostu wiedział, w którym dużym kupie zmian pojawił się problem.

Oto jak działa z Git, ale zasada ma zastosowanie do dowolnej kontroli wersji.

Jasper Kennis
źródło
wydaje się, że nie oferuje to nic istotnego w porównaniu z punktami przedstawionymi i wyjaśnionymi w 10 wcześniejszych odpowiedziach. Poza tym, ostatni akapit wydaje się odnosić do funkcji specyficznych git natomiast pytanie wydaje się być nie na temat git
komara
Dzielenie nie jest specyficzne dla git. Można to zrobić za pomocą dowolnego rodzaju kontroli wersji, to był tylko przykład, ponieważ wiem, że Git ma to wbudowane.
Jasper Kennis
-1

Kiedy:

  • buduje (ZAWSZE)
  • testy jednostkowe są zaliczone
  • działa (chyba że jest wyraźnie oznaczone jako „praca w toku”)
  • korzyści wynikające z zapisania stanu kodu przeważają problemy związane z uruchamianiem testów, myśleniem o dobrym komunikacie zatwierdzenia i rozwiązywaniem wszelkich konfliktów scalania podczas procesu zatwierdzania
quant_dev
źródło
jest to zalecane przez naszą najlepszą praktykę.
jersoft,