Using gitflow, when creating a release-1.0.0
branch and merging it to both master
and develop
, both branches will have a missing commit:
master
wont have the commit whererelease-1.0.0
was merge todevelop
develop
wont have the commit whererelease-1.0.0
was merge tomaster
Instead, after hotfix-1.0.1
is created and merged to master
, when it is being merged to develop
, the commits to merge will include the previous commit where release-1.0.0
was merged to master
; so it will look like this:
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
If this sounds confusing, you can easily notice this everytie you see develop
is usually a couple of commits behind master
(even though develop, theoretically, should only be ahead since it's the main branch. Those commits are merges from release-x.x.x
to master
).
How should this be handled to maintain a clean history?
Best Answer
I think a good approach is to avoid having two "main" branches, master and develop are kind of redundant. It's explained thoroughly here, branded
cactus-flow
by the author.Some points stand out as opposed to git-flow:
For me the last one is important, as after using git-flow for a long time I'm yet to see what's useful about
--no-ff
merges.IMHO that's your big mistake. There's no reason for you to stick to git-flow as much as possible. It may be used in thousands of projects but that does not affect yours, does not make it good.
Git-flow is a good starting point but you should think about adapting it to your tools and workflow rather than the other way around.