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ń.
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ę.
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.