Prevent Master Branch from being ahead of dev

Question

we got a pretty standard git workflow, but i am annoyed by one thing: The master is ahead of development because every deployment we create a merge-commit from dev to master.

At first our workflow:

• master branch - always clean and available for a deployment
• development branch - Collects new features / bug fixes if those are reviewed and approved
• feature branch - a new branch that only has needed changes for one feature (it is branched off development branch)

Every successfull pull request (feature > development) creates a merge-commit, which is fine.

But every deployment (development > master) also creates a merge-commit which only exists in the master. So what happens is that after 20 deployments the master branch is 20 commits ahead of development branch.

How do you deal with that behaviour? Do you merge master > dev from time to time (which actually does nothing but creating a useless merge-commit)?

rebasing development-branch seems not to be an option because then every developer would lose the tracked remote branch.

Breen

Answer 1

What you're asking for is called a "fast forward" merge. Since you mention pull-requests, I assume you're using something to manage your branches for you (GitHub, BitBucket, etc.), so the exact instructions to accomplish what you want may vary.

---

Given this state:

master o-o-o-o
              \
development    o-o-o

Your software likely is applying the --no-ff flag when merging (which is standard behavior because you want the merge commit when merging a feature into development). From the command line this is equivalent to:

git merge --no-ff development

master o-o-o-o-------o
              \     /
development    o-o-o

However, if you want to avoid the merge commit you DO want to fast-forward the branch:

git merge --ff development (The --ff should be unnecessary because it is the default behavior)

master/development o-o-o-o-o-o-o

---

Notes:

1. If you do this, you lose the ability to see when development was merged into master. This may not be a concern (or you may be addressing that in another way, such as with tags).
2. If you do have unique commits on master and a fast-forward is not possible, this will still create a merge-commit. However, you can use the flag --ff-only to error out if a fast-forward is not possible (either unique commits in master or already up-to-date).

Beelzebub

what an awesome explanation, thanks a lot for that!! 😃👾 – Breen

Answer 2

As you can see in the presentation of GitFlow, master is a branch that is always a merge target, never a source. Thus, as you correctly observed, master branch will contain merge commits that no other branch has. That's no problem at all, and at most a cosmetic issue.

Why are you annoyed by this? If you stick to the flow, you will have these commits, but why even care about them? They don't affect the workflow in any way.

Cumbrous

the annoying thing is that git always shows the dev branch as "20 commits behind, 40 commits ahead" thats not the most intuitive thing. and IF we have a hotfix directly in master you couldn't tell that it's missing in dev. – Breen

Where does it show it that way? I only know that type of message from comparisons between a branch and its' upstream, and you wouldn't set master as an upstream for your local develop?! As for the hotfix: Whoever merges it to master should cherry-pick it to develop right away. – Cumbrous

Answer 3

That's how we do it: Branch a release branch from development when you think your features are ready ("code drop"). Run expensive tests there and fix the bugs, then merge release to master, and merge master back to development. Start a new release branch again.

You can merge master back to development after each deployment, too, but without any real changes in the release branch, that doesn't make much sense.

Wolver

Answer 4

We have 3 base branch develop, staging & master. Whatever new feature we build we save in feature/branch & pull changes in develop. Since this feature needs testing so it will be pulled again in Staging branch. On getting sign off from tester we push it to master branch. In comparison to your workflow we have less commit to master branch, but again merge conflict will be still there if you have made any changes in pre-existing code.

Naaman

Your answer should address the question: 'How do you deal with that behaviour?`, rather than suggest another workflow, which the poster may not be able to follow. – Franciscofranciska