Utrzymywanie czystej historii git podczas korzystania z gitflow - niezmergowane zatwierdza się przy programowaniu

Korzystając z gitflow, podczas tworzenia release-1.0.0gałęzi i scalania jej z obydwoma masteroraz developw obu gałęziach będzie brakowało zatwierdzenia:

masternie będzie miał zatwierdzenia gdzie release-1.0.0został scalonydevelop
developnie będzie miał zatwierdzenia gdzie release-1.0.0został scalonymaster

Zamiast tego, po hotfix-1.0.1utworzeniu i scaleniu master, podczas łączeniadevelop , zatwierdzenia do scalenia będą obejmować poprzednie zatwierdzenie, w którym release-1.0.0został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, developjest 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.xdo master).

Jak sobie z tym poradzić, aby zachować czystą historię?

git gitflow

— Christopher Francisco
źródło

Proszę zdefiniować „czystą historię”.

— Jace Browning

Chcesz czystej historii? Nie używaj gitflow. Z definicji zanieczyszcza twoją historię. Zamiast tego zastanów się, czego naprawdę potrzebujesz i zbuduj przepływ pracy, aby pasował do tego, jak chcesz pracować.

— FP

Scalenie z masterem będzie „kopią”, nie trzeba go scalać, aby się rozwijać. Dokonaj poprawek z poprzedniej wersji wydania, a nie master, i stamtąd połącz oba elementy, a nie będziesz mieć problemu. Mistrz nie dodaje wiele do modelu, więc można go całkowicie upuścić, IMO.

— axl

@axl Rozumiem, co masz na myśli, ale staram się śledzić gitflow jak najbliżej jego dokumentacji. Wolałbym nie robić żadnego „hacka”, ponieważ ponieważ wielu programistów już przyjęło gitflow, powinni już mieć rozwiązanie tej prostej rzeczy

— Christopher Francisco,

Istnieje kilka dyskusji na temat rozwiązywania różnych problemów za pomocą GitFlow w GitHub i innych miejscach. Czasami po prostu nie ma srebrnej kuli.

— axl

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-flowprzez autora.

Niektóre punkty wyróżniają się w przeciwieństwie do git-flow:

Tylko jedna główna gałąź
Tylko szybkie przewijanie do przodu

Dla mnie ta ostatnia jest ważna, ponieważ po długim używaniu git-flow nie wiem, co jest przydatne w --no-ffscalaniu.

Staram się śledzić gitflow jak najbliżej jego dokumentacji. Wolałbym nie robić żadnego rodzaju „hackz”, ponieważ ponieważ gitflow jest już adoptowany przez wielu programistów, powinni już mieć rozwiązanie tej prostej rzeczy

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.

— Sergio Basurco
źródło