Czy każdy git commit powinien opuścić projekt w stanie roboczym?

Jestem ciekawy, jaka jest najlepsza praktyka. Czy git commits powinien być wymuszony w taki sposób, aby projekt był w stanie roboczym (buduje się poprawnie, wszystkie testy przechodzą itp.), Czy też popełnianie złamanego kodu jest prawidłowe?

Na przykład, jeśli zniesiesz ten wymóg, możesz być bardziej elastyczny dzięki zatwierdzeniom (użyj ich jako logicznych fragmentów, nawet jeśli aplikacja nie jest w stanie roboczym itp.). Jednak jeśli go narzucisz, zyskasz elastyczność wyboru późniejszego dowolnego zatwierdzenia ...

Zwykle przestrzegam tej zasady:

• Każde połączenie do masteroddziału musi opuścić projekt w stanie roboczym;
• Każde połączenie z developodgałęzieniem linii głównej powinno pozostawić projekt w stanie roboczym (i musi on zbudować przynajmniej);
• Każda inna jednostka popełnić ma podstawowy cel tłumacząc, dlaczego zmiana jest dokonywana, a co to jest za, a jakie części projektu to wpływ. Wszystkie pozostałe cele, takie jak pozostawienie projektu w stanie roboczym, są opcjonalne.

Użyj lokalnego klonu repozytorium do wszystkiego, co zapewnia komfort podczas programowania.

Regularnie popełniam uszkodzony kod, a gdy jestem gotowy udostępnić kod innym programistom, korzystam z doskonałej funkcji:

git rebase -i HEAD~4

To pozwala mi skompresować mój pośredni (w tym przypadku 4 z nich), prawdopodobnie uszkodzony, zatwierdza się w jednym dobrym zatwierdzeniu. Zostanie wyświetlony edytor umożliwiający wybranie sposobu kompaktowania tych zatwierdzeń. Zazwyczaj zaznaczam pierwszy zatwierdzenie jako „pick”, a pozostałe „squash”.

Następnie mogę wcisnąć jeden zatwierdzenie atomowe, a właściwie to, co robię, jeśli moja nowa funkcja jest naprawdę gotowa, to użyć „git cvsexportportcommit”, aby wprowadzić moją pracę do istniejącego repozytorium CVS.

Dwie wielkie zalety kontroli wersji polegają na tym, że pozwala ona programistom odzyskać poprzednie wersje ich pracy, a także umożliwia programistom wypróbowanie różnych, być może sprzecznych zmian w tym samym czasie. Kontrola wersji daje programistom swobodę wypróbowywania pomysłów, które mogą zawieść.

Deweloperzy powinni być zachęcani do regularnego rozgałęziania i angażowania swojej pracy, bez względu na to, czy buduje, czy nie. Odmowa zezwolenia na rozgałęzianie lub łamanie zatwierdzeń oznacza hamowanie programistów i niewłaściwe korzystanie z narzędzi.

To powiedziawszy, jest to doskonała praktyka wymagająca, aby zobowiązania dla niektórych gałęzi zawsze budowały. Wiele organizacji idzie dalej i w ogóle zabrania programistom angażowania się w określone oddziały. Na przykład programiści mogą być zmuszeni do scalenia swojej pracy z powrotem do głównej gałęzi programistycznej, ale tylko wiodący programista może mieć możliwość scalenia tych zmian od rozwoju do gałęzi produkcyjnej.

Generalnie stosujemy oba podejścia. W lokalnym repozytorium na moim urządzeniu zatwierdzam wszystko, czego chcę. Kiedy nadszedł czas, aby przejść do centralnego repozytorium mojego zespołu, najpierw robię interaktywną bazę i formuję swoje zobowiązania w logiczne pakiety. Zazwyczaj jeden zatwierdzenie na historię, z identyfikatorem historii (lub wady) zawartym w komentarzu (jesteśmy sklepem opartym na kanban).

Następnie w naszym centralnym repozytorium słuchamy Jenkinsa i rozpoczyna się wersja i wszystkie testy. Jeśli coś się nie powiedzie, zazwyczaj pozwalamy ludziom spróbować naprawić kompilację za pomocą innego zatwierdzenia. Jeśli nie wygląda to dobrze, cofnięcie błędnego zatwierdzenia jest łatwe.

Od git commit wpływa tylko na twoją kopię repozytorium, nie ma potrzeby, aby projekt był w stanie roboczym po każdym zatwierdzeniu. Śmiało i zobowiązuj się, gdy chcesz zapisać pracę, którą wykonałeś. Prawdopodobnie dobrą zasadą jest to, że zatwierdzenie jest odpowiednie, gdy możesz opisać zmiany, które wprowadziłeś w komunikacie zatwierdzenia.

To git pushwpływa na innych użytkowników. Zasady dotyczące tego, co należy wdrożyć, zależą od decyzji zespołu programistów. Wepchnięcie niedziałającego kodu do głównej gałęzi jest prawdopodobnie nie-nie, ale prawdopodobnie dobrze jest wcisnąć niedziałający kod do osobnej gałęzi (o ile nikt inny nie będzie próbował zbudować z tej gałęzi).

Używamy git flow w pracy, a także popełniamy niedokończony lub uszkodzony kod - ponieważ ląduje on tylko w lokalnych lub zdalnych oddziałach utworzonych dla tego konkretnego problemu. Dopiero po zakończeniu zadania zostaje ono scalone z gałęzią programowania (która reprezentuje bieżącą kopię roboczą w modelu przepływu). W ten sposób możemy również współpracować nad kodem (niektórzy współpracownicy są w innym mieście, w tym kierownik projektu) i pomagać sobie nawzajem.

Zależy to jednak od tego, jak myślisz ty i twoi współpracownicy. Osobiście uważam, że zatwierdzanie oddziałów jest w porządku, ponieważ możesz potrzebować historii zmian z większym refaktorem lub podobnym.

Ostatecznie to zależy od ciebie i ludzi, z którymi współpracujesz lub dla których, ponieważ git nie narzuca żadnych reguł.

Moja praktyka polega na unikaniu wszelkich zobowiązań, które celowo pogarszają system. Każde zatwierdzenie powinno albo refaktoryzować, albo wdrożyć jakiś wymóg. Jeśli dokonam złego zatwierdzenia i odkryję go, zanim go wypchnę, poprawię lub zmienię bazę, aby usunąć go z historii.

Myślę, że dzięki temu łatwiej jest odczytać dziennik git w żądaniu ściągnięcia, ponieważ każde zatwierdzenie powinno stać samodzielnie jako refaktoryzacja lub implementacja jakiegoś wymagania. Dodanie martwego kodu, który zostanie wprowadzony w życie w niedalekiej przyszłości, liczy się jako refaktoryzacja. To są moje „logiczne fragmenty”.

Nadal możesz być elastyczny dzięki temu, jak strukturyzujesz swoje zobowiązania. Na przykład możesz napisać testy z wyprzedzeniem, ale oznaczyć je jako pomijane w pierwszym zatwierdzeniu, aby Twój zestaw testów nie zgłosił awarii, a następnie je pominąć po zakończeniu implementacji.

Zakładając, że używasz rozgałęzień i dobrych komunikatów zatwierdzania, popełnianie „zepsutego” kodu w gałęzi z komunikatem zatwierdzenia, który to wyjaśnia, byłoby w porządku, pod warunkiem, że twój zespół zgadza się, że jest to dobra praktyka robocza.

Klonujesz również repozytorium git lokalnie, więc możesz mieć po prostu lokalny oddział z lokalnymi zatwierdzeniami, które nie są wypychane do źródła, w którym popełniasz „zepsuty” kod; wtedy, gdy wszystko działa, możesz połączyć je w master lub jakiś inny oddział i usunąć działający oddział z różnymi „zepsutymi” zatwierdzeniami.

Dla mnie chodzi o uzgodnienie ze swoim zespołem, co jest dopuszczalne; niektóre zespoły nie zaakceptują zepsutego kodu nawet w oddziale, inne zaakceptują.