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

Zawsze jednak zgadzałem się z mantrą ¹ 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)

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

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ś.

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ć.

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).

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.

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.

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.