I have a project which is also a NuGet package. Because of this, it lives on 2 branches: master, which is used for releasing new official versions, and development, where the actual development takes place. When we want to release a new version, we simply merge commits from development to master.
Our package releasing process includes (and requires) tagging commits. Now, the problem is: in the past when we merged from development to master, the git history for master would contain only commits from development, there were no merge commits (so it'd always add n commits to the history).
However, at some point somebody on the team started doing weird things with branches in this repository and now whenever we merge to master, an empty merge commit is added on top (so it results in n+1 commits added to master history). It contains no files changed, it simply is there. This is mildly annoying, but the real problem here is that now the package tag ends up on the merge commit, something we do not want.
The question is: how can this be fixed so that we no longer get these empty merge commits every time branch is merged into master branch?
- 125
- 3
- 12
-
1I don't know how to fix this, but some people like to always have a merge commit, even when a fast-forward takes place. This is probably why you have this configuration. – Tim Biegeleisen Jan 03 '19 at 11:19
2 Answers
What you want to do is perform fast-foward merges. A fast foward merge can only take place if all changes on your development branch were made on top of the latest commit on master. In this case, if you call git merge with --ff-only, the master branch pointer will be set directly to the latest commit of development.
See this question and linked questions for details on ff and non-ff merges.
The opposite of this would be the --no-ff argument, which enforces a merge commit even if none is necessary.
Be aware that if you use GitLab, GitHub or something similar, there may be settings to ajust if merge commits are enforced or not.
- 12,647
- 2
- 28
- 41
From what you describe, the history of master has diverged from that of development. This divergence can be as small as a commit that was rebased to amend the commit message, author, or sign-off. Even if the trees of the two branches are exactly the same, the history remains different. Consequently, git cannot perform a fast-forward merge where it only updates master to point at the latest commit in development. Instead, a real merge commit is created to record the difference in history between master and development.
If the above description is correct, you can easily fix this situation by merging master into development once, ideally right after merging development into master.
After this merge (which should be a fast-forward if it happens right after a release-merge), master will again be a part of the history of development, so future merging of development into master will fast-forward master to the current state of development again.
- 38,891
- 9
- 62
- 106