Czy historia wersji jest naprawdę święta, czy może lepiej jest bazować?

26

Zawsze jednak zgadzałem się z mantrą 1 Mercuriala , jednak teraz, gdy Mercurial jest dostarczany w pakiecie z rozszerzeniem rebase i jest to popularna praktyka w git, zastanawiam się, czy naprawdę można to uznać za „złą praktykę”, a przynajmniej wystarczająco zły, aby uniknąć używania. W każdym razie jestem świadom, że odpychanie się jest niebezpieczne po pchnięciu.

OTOH, myślę, że warto spakować 5 zatwierdzeń w jednym, aby wyglądało to lepiej (szczególnie w oddziale produkcyjnym), jednak osobiście uważam, że lepiej byłoby zobaczyć częściowe zatwierdzenia funkcji, w której niektóre eksperymenty są przeprowadzane, nawet jeśli nie są tak fajne, ale zobaczenie czegoś w rodzaju „Próbowałem zrobić to tak, jak X, ale mimo wszystko nie jest tak optymalne jak Y, zrób to Z biorąc Y jako bazę” miałoby dobrą wartość dla osób studiujących baza kodów i podążaj za tokiem myślenia twórców.

Moim bardzo upartym (jak w głupim, trzeźwym, stronniczym) punktem widzenia jest to, że programiści lubią bazę, aby ukryć błędy ... i nie sądzę, żeby to w ogóle było dobre dla projektu.

Więc moje pytanie brzmi: czy naprawdę ceniłeś sobie takie „organiczne zatwierdzenia” (tj. Niezakłóconą historię) w praktyce? Lub odwrotnie, czy wolisz wpaść w fajne, dobrze zapakowane zobowiązania i zignorować proces eksperymentowania programistów ?; którykolwiek wybierzesz, dlaczego to działa dla ciebie? (angażowanie innych członków zespołu do przechowywania historii lub, alternatywnie, przekształcanie jej)


1 na analizę Google DVCS w Mercurial „History is Sacred”.

dukeofgaming
źródło
czy mógłbyś podać odniesienie do miejsca, w którym jest ono określane jako „mantra Mercuriala”?
komara
Teraz, gdy o tym wspominasz, myślę, że tak naprawdę pochodzi on z analizy Google DVCS code.google.com/p/support/wiki/DVCSAnalysis (ale fakt pozostaje)
dukeofgaming

Odpowiedzi:

22

Historia jest Święte, obecny nie jest. Możesz podzielić swoje „drzewo” DVCS na dwie części:

  • Przeszłość / historia, która zawiera dokładny obraz tego, jak została osiągnięta aktualny stan kodu. Ta część historii rośnie z czasem

  • Obecny których część aktualnie pracuje nad aby ci kodu ewoluować. Ta wskazówka w przeważającej części historii ma zawsze ten sam rozmiar.

Każdy kod, który wydałeś lub wykorzystałeś w jakiś sposób, należy do przeszłości . Przeszłość jest święta, ponieważ musisz być w stanie odtworzyć konfigurację lub zrozumieć, co wprowadziło regresję. Nigdy nie przepiszesz przeszłości . W git zwykle nigdy niczego nie przepisujesz, gdy jest w master: master jest przeszłością . W Mercurial masz koncepcję fazy publicznej, która śledzi przeszłą część twojego „drzewa” i wymusza jego niezmienność.

Obecna część kodu są changeset aktualnie pracuje. Gałąź funkcji, którą próbujesz uczynić użyteczną, wolną od błędów i odpowiednio zrefaktoryzowaną. Przepisanie go jest w porządku , jest nawet dobrym pomysłem, ponieważ sprawia, że część z przeszłości jest ładniejsza, prosta i użyteczna. Mercurial śledzi to w fazie draftu .

Więc tak, proszę o zmianę bazy, jeśli poprawi to twoją historię. Mercurial zapobiegnie wystrzeleniu się w stopę, jeśli bazujesz na materiałach, których nie powinieneś.

Marmoute
źródło
Teraz bardziej podobała mi się twoja odpowiedź
dukeofgaming,
7

Nie wszystkie błędy są tego rodzaju, które trzeba ukryć - na przykład kiedyś przypadkowo przekazałem plik binarny do mojego repozytorium. Manipulowanie historią jest złe tylko wtedy, gdy wina nie dotyczy wyłącznie samej historii, np. Popełnionych plików, których nie powinno być.

DeadMG
źródło
1
Więc nigdy nie zrobiłbyś bazowania, aby uczynić zatwierdzenie bardziej „logicznym”?
dukeofgaming
7

Przeglądanie kodu jest o wiele łatwiejsze, gdy występuje jedna duża spójna zmiana, w przeciwieństwie do wielu małych zależnych.

Kiedy pracuję nad nową funkcją, lubię wprowadzać wiele małych zmian w moim oddziale. Kiedy jestem gotowy do przesłania łatki, zwijam te małe zatwierdzenia w jedno duże zatwierdzenie, które reprezentuje cały nowy kod wymagany dla tej funkcji. Tutaj przydaje się rebase.

Z drugiej strony, odradzanie jest niewskazane, jeśli commity nie mają ze sobą nic wspólnego. Wiele dodatków funkcji powinno być osobnymi zatwierdzeniami (najlepiej pochodzącymi z oddzielnych gałęzi).

chrisaycock
źródło
4
istnieje wiele narzędzi, które sprawiają, że przegląd kodu wielu powiązanych zmian jest dość trywialny, więc sam nie kupuję tego jako odpowiedzi
jk.
4
Jaka jest różnica między przeglądaniem różnicy między wersją podstawową a wersją pełną funkcji, a przeglądaniem pojedynczego zatwierdzenia tego zestawu ponownie zatwierdzonych zmian? Będzie wyglądać identycznie, jeśli baza ponownie wykona swoją pracę poprawnie!
Mark Booth
3
To, co tu opisujesz, jest sprzeczne z radami na wiki Mercurial . Małe „oczywiście poprawne” zestawy zmian są preferowane w recenzjach. Zwijanie gałęzi funkcji w pojedynczy zestaw zmian nie jest normalne w Mercurial - widziałem, że jest to zalecane znacznie częściej w Git, gdzie git rebase -ipozwala to zrobić łatwo i selektywnie. Najbliższy odpowiednik Mercurial to histedit .
Martin Geisler,
9
Całkowicie się nie zgadzam. W ciągu ostatnich kilku lat korzystaliśmy z narzędzia do recenzji kodu i nie było nic, czego nienawidzę więcej, gdy jeden duży zestaw zmian ponad 30 plików został przesłany do recenzji. Dużo łatwiej jest uzyskać wiele drobnych zmian. Np. Przemianowałem tę klasę na xyz, ponieważ lepiej odzwierciedla ona zmodyfikowaną odpowiedzialność. Dodałem metodę nn, ponieważ będę jej potrzebować dla bla. Znacznie łatwiej jest obsługiwać mniejsze recenzje.
Pete
3
Słyszałem o tym dość często w społeczności gitów polegającej na zwijaniu wielu zmian w jeden, zanim przejdziesz do oficjalnego repozytorium, ale to nigdy mi nie pomogło. Wolałbym raczej małe zatwierdzenia z sensownymi wiadomościami. Jak zauważyli inni, możesz zrobić różnicę między wieloma zestawami zmian.
Chris Sutton,
4

Twoje pytanie opisuje historię jako zestaw uporządkowanych zmian w kodzie i pyta, czy organiczne zatwierdza wskazówki przyszłych czytelników w procesie rozwoju. Jednak jako inżynier ds. Wydań / integracji często nie myślę o historii jako o kodzie. Jestem bardziej pochłonięty historią, którą opowiada moja historia, zachowaną wiedzą instytucjonalną i tym, czy pozwala mi to szybko debugować problemy.

Nie sądzę, by organiczne przepływy pracy działały tak dobrze, nawet moje. Cechy, które cenię w DVCS, gdy koduję - tanie oddziały, szybkie zatwierdzanie, zapisywanie na pilocie wcześnie i często - nie są tym, co cenię jako menedżera integracji mojej firmy . Mam problem git rebase, git merge, git diff, a git applyznacznie częściej w tej roli niż git addlub git commit. Narzędzia takie jak rebasepozwalają mi przekształcić otrzymany kod z czegoś, co funkcjonuje, w coś, co można utrzymać.

Nielogiczne lub niejasne zatwierdzenia nie są przydatne, ale są grzesznie łatwe do pisania organicznego, gdy główną troską jest sprawienie, by kod działał, a nie rozpowszechnianie go wśród innych. Zobowiązuje się podoba Case 15: Fixed a problem, albo Refactored <cranky legacy feature>zrobić mój konserwacji samodzielne warować, nawet wtedy, gdy ich autor. Żadne jednak nie wywołuje szału zaciemnienia, takiego jak zatwierdzenia „przyrostowe”. Rozważ tę gałąź tematu, którą programista podał mi kiedyś:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

Te rzeczy są złe. To jest jak DVCS zaprojektowany dla Dr. Faustusa. Dam ci szybką i łatwą kontrolę źródła. Dajesz mi duszę swojego twórcy kodu. Wszystkie leniwe zobowiązania są aktami samolubnymi. Wielu z nas je pisze, ale naszą przyszłość zawdzięczamy także logicznej, powtarzalnej i debugowalnej historii. Nie możemy tego zrobić bez jakiegoś sposobu rebase.

Jeśli chodzi o nieudane eksperymenty, dlaczego nie opisać ich w naszych (nowo nieskazitelnych) komunikatach zatwierdzających? Za rok nie potrzebuję na wpół skończonego fragmentu. Chcę tylko zapis przerwanej próby i być może krótkie wyjaśnienie, jeśli uważam, że jestem na tyle głupi, by spróbować ponownie. Na świecie istnieje wiele udanych przepływów pracy, ale staram się wymyślić jakiś powód, dla którego świadomie popełniam uszkodzony kod w bazie kodu produkcyjnego.

Krzysztof
źródło
Bardzo fajna odpowiedź, krystalicznie czyste motywacje, dlaczego warto
bazować
2

Nic nie powinno być święte, ale upewnij się, że masz dobre powody tego, co robisz. Rebasing jest niezwykle potężny, gdy jest właściwie stosowany, ale podobnie jak w przypadku każdego potężnego narzędzia, może być mylący i powodować problemy, jeśli jest używany beztrosko.

Osobiście uważam, że bardzo przydatne jest przestawienie lokalnej gałęzi funkcji na magistralę (lub główną gałąź programistyczną) przed uruchomieniem końcowych testów i scaleniem funkcji w gałęzi głównej. W ten sposób radzę sobie z wszelkimi konfliktami scalania itp. Przed faktycznym połączeniem.

Harald
źródło
1

IMHO, eksperymenty zwykle należą do półek lub tymczasowych gałęzi, a nie linii podstawowych. Jeśli to zrobisz, nie powinno być problemu, ponieważ wszystkie zatwierdzenia będą logicznie poprawne i dodadzą pewnej wartości.

Koder
źródło
Mówisz, że wolisz działające gałęzie niż edytowanie gałęzi podstawowej (tj. Master / default, produkcja / wydanie, vX.X itp.)?
dukeofgaming