1

Using git I have two long-lived branches: master and develop. Feature branches are taken from develop and then merged back into develop upon completion. Once we're happy we then merge the contents into master.

The "issue" I have is that master is now one commit ahead of develop. So the next branch that is taken from the tip of develop is one commit behind master. Should I be concerned about this?

I know this can be dealt with by performing a fast-forward merge into master (and therefore not creating the extra merge commit), but do I actually need to care about this? The reason I ask is because it feels like develop is going to become increasingly diverged from master upon each new feature->develop->master merge.

EDIT: I'm using GitLab / GitHub. The Merge Request / Pull Request feature necessitates a non-fast-forward merge.

1 Answers1

2

The only concern I'd have is why master needs to merge with develop at all. It should be a fast-forward. That suggests that there's things in master which are not in develop, like hot patches, and so you're not developing on top of everything which is in production.

You should have a situation like this:

  B - C   E - F   H - I
 /     \ /     \ /     \
A ----- D ----- G ------ J [develop]
        [master]

master is at D and has had a feature branch (B, C, D) previously merged in. develop is at J and has had two feature branches merged in. When you git checkout master; git merge develop it should be a simple fast-forward to J.

If you need a merge, it means master and develop have diverged. That probably means someone hot patched master and that patch hasn't gone back into develop. For example, the hot patch is E.

  B - C   E - F   H - I
 /     \ /     \ /     \
A ----- D ----- G ------ J [develop]
         \
          L [master]

Now when you git checkout master; git merge develop it will need to merge.

  B - C   E - F   H - I
 /     \ /     \ /     \
A ----- D ----- G ------ J [develop]
         \                \
          L -------------- K [master]

This will continue to happen.

This is more than a nuisance. It means develop never truly reflects the code that will run in master after the merge. You're developing and testing on a slightly different code base than what's in production. Eventually you'll merge a fully tested develop into master and production will break.

You'll probably want to look and see if there's any commits in master which are not in develop using one of these techniques and cherry-pick them into master.

Alternatively, instead of merging you could rebase develop onto master, probably using -p to preserve your feature branches. Then merge (ie. fast forward).

That would go something like this, starting with the hot patched master...

  B - C   E - F   H - I
 /     \ /     \ /     \
A ----- D ----- G ------ J [develop]
         \
          L [master]

Then git checkout develop; git rebase -p master.

  B - C        E1 - F1  H1 - I1
 /     \      /      \ /      \
A ----- D - L ------ G1 ------ J1 [develop]
            [master]

Now you can fully test develop knowing it has everything it will have once "merged" into master.

Community
  • 1
  • 1
Schwern
  • 153,029
  • 25
  • 195
  • 336
  • Interesting and very helpful response - thanks!. What's your opinion when a non-fast-forward merge is required (perhaps due to GitLab's / GitHub's mechanism of managing Merge Requests / Pull Requests)? –  Mar 06 '17 at 19:08
  • @thehowler If you're using Github PRs for the develop -> master merge, that explains why you're always a commit behind. In that case that's fine, but you probably shouldn't be doing merges into production as a Github PR, you'll want finer control. An alternative to the rebase strategy above is to merge develop in, delete develop, tag the location (so you know it's a release), and create a new develop off master. – Schwern Mar 06 '17 at 19:27
  • thank you for the clarification. My question should state this GitLab / Github constraint. I'll edit it and upvote you answer. –  Mar 06 '17 at 19:30
  • @thehowler Git(hub|lab) put no constraint on how you use Git. You can do the merge, or anything else you like, to the repo from the command line or any Git tool. – Schwern Mar 06 '17 at 19:33
  • Yes - understood. –  Mar 06 '17 at 19:40