Korzystając z gitflow, podczas tworzenia release-1.0.0
gałęzi i scalania jej z obydwoma master
oraz develop
w obu gałęziach będzie brakowało zatwierdzenia:
master
nie będzie miał zatwierdzenia gdzierelease-1.0.0
został scalonydevelop
develop
nie będzie miał zatwierdzenia gdzierelease-1.0.0
został scalonymaster
Zamiast tego, po hotfix-1.0.1
utworzeniu i scaleniu master
, podczas łączeniadevelop
, zatwierdzenia do scalenia będą obejmować poprzednie zatwierdzenie, w którym release-1.0.0
zostało scalone master
; więc będzie wyglądać tak:
User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.
* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug
Jeśli brzmi to myląco, możesz łatwo zauważyć, że to, co widzisz, develop
jest zwykle o kilka opóźnień w tyle master
(chociaż rozwijanie teoretycznie powinno tylko być z wyprzedzeniem, ponieważ jest to główny oddział. Commity te są scala od release-x.x.x
do master
).
Jak sobie z tym poradzić, aby zachować czystą historię?
Odpowiedzi:
Myślę, że dobrym podejściem jest unikanie posiadania dwóch „głównych” gałęzi, opanowanie i rozwój są w pewnym sensie zbędne. Zostało to dokładnie wyjaśnione tutaj , sygnowane
cactus-flow
przez autora.Niektóre punkty wyróżniają się w przeciwieństwie do git-flow:
Dla mnie ta ostatnia jest ważna, ponieważ po długim używaniu git-flow nie wiem, co jest przydatne w
--no-ff
scalaniu.IMHO to twój wielki błąd. Nie ma powodu, abyś trzymał się git-flow w jak największym stopniu. Może być stosowany w tysiącach projektów, ale to nie wpływa na twój, nie czyni go dobrym.
Git-flow jest dobrym punktem wyjścia, ale powinieneś pomyśleć o dostosowaniu go do swoich narzędzi i przepływu pracy, a nie na odwrót.
źródło