Git - alternatywa dla cherry-pick

Witam,

Prowadzę projekt, który ma dwie gałęzie: dev i master.
Branch dev zawiera wszystkie zmiany jakie są dokonywane w projekcie.
Branch master zawiera tylko te zmiany, które zostały zaakceptowane przez klienta.

Czasami dochodzi do sytuacji, że klient zatwierdzi pewien commit po upływie kilku miesięcy.
W jaki sposób radzić sobie z takimi starymi poprawkami?
Blokuje mi to łączenie gałęzi przez co muszę się posiłkować cherry-pickami.
Dodatkowo nie widzę wówczas zmian pomiędzy branchami:

git log dev..master

Nijak, przy takim flow masz dwie oddzielne historie. Rozwiązania jakie widzę:

• okresowo tworzysz nowy release z deva, ale zgaduję, że to niemożliwe w tej sytuacji
• przeniesienie problemu na kod przy użyciu feature switchów

Też bym pomyślał o stosowaniu feature flag tam, gdzie się da. Zatwierdzanie zmian po wielu miesiącach na poziomie zmian w kodzie brzmi jak drugie tyle roboty po zatwierdzeniu, przypuszczam że po takim czasie zmiany mogą pasować jak pięść do nosa jeśli to nie jest coś czysto przyrostowego np nowy moduł, nowe API, nowa funkcja w UI itp

Możesz powiedzieć szerzej jak wygląda proces wytwarzania oprogramowania?

Korzystacie z feature branchy? Jak często są wprowadzane zmiany do deva / mastera? Macie tagi? Releasy? Każdy commit na masterze to osobny release z jedną funkcjonalnością?

Po mojemu, w takiej sytuacji należy robić odrębny branch dla każdej funkcjonalności i przenosić (merge) na mastera po zatwierdzeniu. Jeśli masz jakiś kod zależny, i tak nie powinieneś go wrzucać na mastera, póki nie zaakceptujesz zależności.

Wiara czyni cuda napisał(a):

Czasami dochodzi do sytuacji, że klient zatwierdzi pewien commit po upływie kilku miesięcy.

Dlaczego klient włazi wam w commity? To jest klient czy… kierownik?

Dlaczego klient włazi wam w commity?

@Azarien: myślę, że OP użył skrótu myślowego. Nie chodziło mu tutaj stricte o grzebanie w commitach, ale o sytuację, że najpierw klient mówi "dodajmy tutaj zielony przycisk, który wyświetli podsumowanie". Ktoś nad tym pracuje, ale klient się do tematu nie chce ustosunkować. W międzyczasie projekt leci do przodu, dochodzą nowe commity, część starego kodu jest zmieniania. Po jakimś czasie klient mówi "OK, ten zielony przycisk mi się podoba i możemy go wdrożyć". Tyle, że stan kody w chwili tworzenia tego przycisku się różni od tego, który mamy w momencie akceptacji, przez co takie proste zassanie tego kodu do mastera nie będzie wcale takie proste i trywialne.

cerrato napisał(a):

@Azarien: myślę, że OP użył skrótu myślowego. Nie chodziło mu tutaj stricte o grzebanie w commitach, ale o sytuację, że najpierw klient mówi "dodajmy tutaj zielony przycisk, który wyświetli podsumowanie". Ktoś nad tym pracuje, ale klient się do tematu nie chce ustosunkować. W międzyczasie projekt leci do przodu, dochodzą nowe commity, część starego kodu jest zmieniania. Po jakimś czasie klient mówi "OK, ten zielony przycisk mi się podoba i możemy go wdrożyć". Tyle, że stan kody w chwili tworzenia tego przycisku się różni od tego, który mamy w momencie akceptacji, przez co takie proste zassanie tego kodu do mastera nie będzie wcale takie proste i trywialne.

Rozwiązaniem jest robienie feature branchy od czasu do czasu synchowanych z masterem.

Każde podejście będzie generować dodatkową pracę. Dla osobnych gałęzi trzeba by co jakiś czas robić merge albo rebase. Można robić rebase dopiero przed mergem, ale zbyt wiele od cherry-picka pod względem wykonywanej roboty nie będzie się to różnić. Przy dwóch wersjach produktu (dev, master) macie sprytniejszego kopi-pejsta. Też żmudna robota. Feature flag wydają się spoko, ale jeżeli macie dużo takich niezaakceptowanych funkcjonalności, które wchodzą w interakcje z innymi niezaakceptowanymi funkcjonalnościami, to robi się nieciekawie.

Wywalić dev w ogóle, mergować featury do mastera, gdy klient będzie ich chciał.

A czy to jest tak rzeczywiście problem z gitem? Każdy sposób będzie zły, bo wiąże się z taką samą robotą.

Może -- w takiej sytuacji -- trzeba przemyśleć architekturę projektu? Może jakieś wtyczki czy coś, żeby każdy ficzer można było łatwo włączać/wyłączać?

lubie_programowac napisał(a):

Możesz powiedzieć szerzej jak wygląda proces wytwarzania oprogramowania?

Korzystacie z feature branchy? Jak często są wprowadzane zmiany do deva / mastera? Macie tagi? Releasy? Każdy commit na masterze to osobny release z jedną funkcjonalnością?

Dla większości przypadków 1 commit = 1 task utworzony przez klienta. Wszystko wówczas leci prosto na dev.
Jeżeli jest większa funkcjonalność tworzymy osobny branch i po jakimś czasie mergujemy do dev.
Release nie stosuję m. in. z racji problemów dot. przestojów zadań.

somekind napisał(a):

Wywalić dev w ogóle, mergować featury do mastera, gdy klient będzie ich chciał.

dev jest wpięty do instancji służącej do testów więc tego zrobić nie mogę.

cerrato napisał(a):

Dlaczego klient włazi wam w commity?

@Azarien: myślę, że OP użył skrótu myślowego. Nie chodziło mu tutaj stricte o grzebanie w commitach, ale o sytuację, że najpierw klient mówi "dodajmy tutaj zielony przycisk, który wyświetli podsumowanie". Ktoś nad tym pracuje, ale klient się do tematu nie chce ustosunkować. W międzyczasie projekt leci do przodu, dochodzą nowe commity, część starego kodu jest zmieniania. Po jakimś czasie klient mówi "OK, ten zielony przycisk mi się podoba i możemy go wdrożyć". Tyle, że stan kody w chwili tworzenia tego przycisku się różni od tego, który mamy w momencie akceptacji, przez co takie proste zassanie tego kodu do mastera nie będzie wcale takie proste i trywialne.

Ten komentarz dobrze odzwierciedla bieżącą sytuację w projekcie.
Do tej pory starałem się tym sterować po stronie kodu w ten sposób, że dana funkcjonalność stanowiła osobny moduł.
Jeżeli klient jej nie zaakceptował mergowałem do master oraz wyłączałem moduł.
Dla przypadku, który pojawił się niedawno tego zrobić nie mogę ponieważ wchodzi on w skład modułu, który na produkcji musi pozostać włączony.
Rozdzielanie zadań do osobnych branchy niewiele różni się od cherry-picka, bo i tak dwie główne gałęzie dev i master będą miały osobne historie zmian.

Można mieć branch per feature i robic na nich rebase z masterem co kilka dni, zeby cały czas były "gotowe" do mergowania, ale przy duzej ilości takich wiszących zmian będzie to dość kosztowne.
Można mieć feature toggle więc zmiany wchodzą do mastera tylko są za jakimś ifem i można je włączyć lub wyłączyć.
Ostatnia opcja to nie implementować ficzera jeśli klient nie jest zdecydowany go wdrażać :)

Tutaj na problem składa się kilka czynników, o czym wspominali koledzy wyżej. Ale podstawowym źródłem problemu jest to że deklarowane wymagania klienta nie są tym czego klient rzeczywiście wymaga w najbliższym czasie, co doprowadza do patologi jaką opisujesz gdzie kod odbiega od tego co rzeczywiście powinno być dostarczone. Można to obejść stosując w/w feature flags, ale to oczywiście oznacza że kod z danym feature (czyli de facto commitem) i tak będzie szedł na produkcję. Najprostszym z technicznego punktu widzenia rozwiązaniem jest zmiana strategii dostarczania aktualizacji- klient deklaruje że w następnym releasie chce takie i takie nowości/zmiany, a Wy deklarujecie że je dostarczycie. Kiedy przychodzi do testowania przez klienta na środowisku przedprodukcyjnym to klient sprawdza czy wszystko działa jak należy, a nie decyduje czy życzy sobie dany feature (już gotowy) teraz czy też później. W wyjątkowych sytuacjach wyłączamy daną zmianę za pomocą w/w feature flag.

Jeśli chodzi o sam Git to ja ogólnie odnoszę wrażenie że zespoły często nadmiernie komplikują zarządzanie branchami. Owszem, powstało wiele ciekawych rozwiązań jak np. Git Flow, ale moim zdaniem lepiej korzystać wybiórczo z tego co ze rozwiązania proponują, bo w większości przypadków wystarczy znacznie prostsze podejście. Np. w takim Git Flow sama idea feature branchy jest świetna, ale już rozbijanie się na dev i master branches (a czasem jeszcze więcej) to często przerost formy nad treścią. Są oczywiście wyjątki od reguły, ale z własnego doświadczenia mogę powiedzieć że najczęściej wystarczy znacznie prostsze podejście- jest master branch, i krótkotrwałe feature branche tworzone dla konkretnego taska/ticketa. Kiedy zmiany są gotowe, mergujemy feature branch z powrotem do mastera. Master jest więc stale aktualizowany, i co jakieś czas robi się z niego release.