9

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 where release-1.0.0 was merge to develop
  • develop wont have the commit where release-1.0.0 was merge to master

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?

Improve this question
7
  • Please define "clean history". Commented Nov 3, 2016 at 21:45
  • 3
    Want a clean history? Don't use gitflow. It by definition pollutes your history. Instead, think about what you really need and build a workflow around that, so it actually fits how you want to work. Commented Nov 4, 2016 at 9:28
  • 1
    The merge to master will be a "copy", no need to merge it to develop. Make hot fixes from the previous release branch, not master, and merge to both from there, and you won't have the problem. Master is not adding much to the model so you can actually drop it completely, IMO. Commented Nov 5, 2016 at 14:30
  • @axl I understand what you mean, but I'm trying to follow gitflow as close as possible to it's documentation. I'd rather not doing any kind of "hackz" because since gitflow is already adopted by many many developers, they should already have a solution for this simple thing Commented Nov 9, 2016 at 2:47
  • There are several discussions about how to solve various issues with GitFlow on GitHub and other places. Sometimes there just isn't a silver bullet. Commented Nov 9, 2016 at 23:49

1 Answer 1

Reset to default
4

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:

  • Just one main branch
  • Only fast-forward merges

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.

I'm trying to follow gitflow as close as possible to it's documentation. I'd rather not doing any kind of "hackz" because since gitflow is already adopted by many many developers, they should already have a solution for this simple thing

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.