Используя gitflow, при создании release-1.0.0
ветви и объединении ее с обеими ветвями master
и develop
обеими ветвями будет отсутствовать коммит:
master
не будет коммит, гдеrelease-1.0.0
было слияние сdevelop
develop
не будет коммит, гдеrelease-1.0.0
было слияние сmaster
Вместо этого после hotfix-1.0.1
создания и слияния с ним master
, когда слияния с develop
, коммиты для слияния будут включать в себя предыдущий коммит, с которым release-1.0.0
был слит master
; так это будет выглядеть так:
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
Если это звучит запутанно, вы можете легко заметить, что все, что вы видите develop
, обычно отстают на пару коммитов master
(хотя разработка, теоретически, должна быть только впереди, поскольку это основная ветвь. Эти коммиты являются слиянием с release-x.x.x
в master
).
Как с этим обращаться, чтобы поддерживать чистую историю?
Ответы:
Я думаю, что хороший подход состоит в том, чтобы избежать двух "основных" веток, master и development, которые являются избыточными. Это подробно объяснено здесь , заклейменным
cactus-flow
автором.Некоторые моменты выделяются в отличие от git-потока:
Для меня важно последнее, так как после долгого использования git-flow мне еще предстоит увидеть, что полезного в
--no-ff
слияниях.ИМХО это твоя большая ошибка. У вас нет причин придерживаться мерзавца настолько, насколько это возможно. Он может быть использован в тысячах проектов, но это не влияет на ваш, не делает его хорошим.
Git-flow - хорошая отправная точка, но вы должны подумать об адаптации его к своим инструментам и рабочему процессу, а не наоборот.
источник