Czy dobrze jest mieć przerwane pośrednie zatwierdzenia, dopóki działa ostateczne zatwierdzenie w jakimkolwiek wypychaniu?

Powiązane: Czy każdy git commit powinien pozostawić projekt w stanie roboczym?

Załóżmy, że lokalnie wykonuję następujące zatwierdzenia:

• Zmodyfikuj schemat bazy danych, psując aplikację.

• Zaktualizuj aplikację, aby była zgodna ze schematem bazy danych.

Tak długo, jak pcham oba zatwierdzenia, masterpozostaje w stanie roboczym. Jednak historyczna wersja jest zepsuta.

Wiem, że mogę użyć git rebase -ido zmiażdżenia zatwierdzeń. Jednak wynikowe zatwierdzenie będzie duże i mniej opisowe. Jeśli muszę przeszukać historię zatwierdzeń, aby dowiedzieć się, dlaczego coś zmieniłem, wolę znaleźć oryginalne zatwierdzenie pokazujące, co zrobiłem i dlaczego.

Moje pytania to:

• Czy ktoś napotkał trudności z powodu złamanych historycznych zobowiązań w kapitale?

• Jeśli tak, to czy istnieje prosty sposób na uniknięcie takich trudności bez odrzucania poszczególnych komunikatów i zmian zatwierdzeń?

W dużej mierze zależy od strategii rozgałęziania twojego stroju, ale myślę, że złamanie zobowiązań w gałęziach programistycznych ma ogólnie sens - naprawdę duża „wygrana” w używaniu kontroli źródła polega na możliwości wycofania drobnych zmian, a czasem jesteś zrób ich kilka, a ty musisz rozbić jajka, żeby zrobić omlety.

Prostym sposobem na zachowanie pojedynczych zatwierdzeń bez zanieczyszczania wzorca jest użycie rozgałęzień. Możesz umieścić tam przełomowe / eksperymentalne rzeczy, aby mieć dokładną historię bez zanieczyszczania historii głównej gałęzi.

Złamane zobowiązania są czymś, co „po prostu się dzieje”, nie powinno oznaczać końca świata. Mam z tyłu głowy trochę dokuczliwy głos, który mówi mi, że nie należy świadomie sprawdzać zepsutego kodu, co do zasady, a zatem także wersji historycznych, ale nie jest to coś, o co bym poszedł na wojnę.

Bardzo chwalony przez Git model rozgałęziania pozwala na utrzymanie zepsutych zatwierdzeń dla określonych gałęzi, np. Jeśli twój zespół przyjmuje gitflow lub jego uproszczoną wersję. Wszystko z polityką „czystego wzorca”. W takim przypadku można sprawdzić ostateczną wersję roboczą jako zatwierdzenie scalania, w którym (uszkodzone) wersje historyczne są dostępne w repozytorium, ale poza linią główną.

Jeśli twój zespół nie przyjął takiego rozgałęzionego modelu, masz uzasadnioną wymówkę, aby po prostu popchnąć całą sprawę do opanowania i skończyć z tym.

Nie, nie jest dobrze.

Jeśli kiedykolwiek zrobiłeś git bisect(a kto nie lubi tej funkcji zabójcy), znasz wartość historii, w której buduje się każde zatwierdzenie.

Jeśli masz wiele zatwierdzeń podczas bisectnie budowania, będziesz mieć wiele git bisect skips, które utrudniają znalezienie ostatniego dobrego zatwierdzenia.

Jeśli zakończysz gałąź funkcji i połączysz ją w master, oczyść gałąź przed połączeniem, aby twoja historia była przejrzysta i rozbudowana.

Czy ktoś napotkał trudności z powodu złamanych historycznych zobowiązań w kapitale?

Tak. Cofanie, cofanie i dzielenie na części są trudniejsze. Podobnie jak czytanie historii (patrz poniżej).

Jeśli tak, to czy istnieje prosty sposób na uniknięcie takich trudności bez odrzucania poszczególnych komunikatów i zmian zatwierdzeń?

Nie wiem, chociaż gałęzie są dobrym rozwiązaniem.

Myślę jednak, że odrzucanie (a raczej zgniatanie) poszczególnych zobowiązań jest słuszne.

Podczas opracowywania, szczególnie podczas TDD, wczesne i częste popełnianie jest dobre. Chcesz mieć pełny ślad tego, co robisz, abyś mógł wrócić lub dokładnie dowiedzieć się, kiedy coś poszło nie tak (a może wpadłeś w refaktoryzację większą niż możesz żuć). Oddaj się.

Jednak gdy funkcja / zmiana jest gotowa do wypchnięcia, zatwierdzenie jest zmianą spakowaną - idealnie atomową, aby można ją było [przeglądać, przekształcać, scalać, wybierać z wiśni, cofać, przeglądać w adnotacjach] tak niezależnie od innych zmian, jak to możliwe .

Patrząc na historię projektu, zmianę oprogramowania należy oceniać samodzielnie. Czy to buduje? Czy pochodzi z testami? Czy to działa? Co to robi? Jakie pliki należy zmienić, aby zapewnić tę funkcję?

Konieczność składania commits, chociaż jest możliwa (i wspomagana przez fuzje), utrudnia to. Dlatego uważam, że wyczyszczenie historii przed wypchnięciem jest właściwe, nawet jeśli oznacza to utratę kontroli nad tym, jak dotarłeś do miejsca, w którym jesteś.

Krótka odpowiedź: tak

Testowanie:

Programowanie oparte na testach oznacza, że ​​piszesz testy, które psują się (tzn. Wykazują błędy).
Następnie piszesz kod, aby testy działały.

Rozwój:

Zobowiązuj się mało, zobowiązuj się często.
Każde zatwierdzenie jest punktem wycofania. Jeśli zdasz sobie sprawę, że jesteś na złej ścieżce, możesz stosunkowo łatwo cofnąć się do poprzedniego punktu. Jeśli twoje zatwierdzenia są wystarczająco drobnoziarniste, możesz cofnąć się do właściwego punktu.

Zastrzeżenie:

To nie znaczy

1) Sprawdzasz uszkodzony kod w master.
2) Musisz wcisnąć wszystkie mikro zatwierdzenia, aby każdy mógł je przejrzeć.

Użyj gałęzi, aby wykonać swoją pracę. Potencjalnie kompresuj mikro zatwierdzenia dla procesów przeglądu, aby były one w logicznie odrębnych jednostkach z odpowiednimi komentarzami. Jeśli używasz git, nie utracisz oryginalnego zestawu zatwierdzeń, możesz po prostu utworzyć nowy, bardziej logiczny zestaw zatwierdzeń dla procedur przeglądu, które zostaną scalone w master.

Myślę, że dopóki zatwierdzenia są lokalne i nie są przekazywane innym, to nie tylko jest ok, to jest naprawdę dobry sposób na pracę. Po prostu nie wysyłaj innym uszkodzonego kodu.