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.

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).

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.