Avoiding merge commits in pull requests in git

Question

So, I want to create a pull request that only includes the changes to file1, file2, and file3 (i.e. updates for a feature).

The workflow I used:

git clone https://github.com/eghm/project.git project-eghm-clean
cd project-eghm-clean
git remote add upstream https://github.com/forkeduser/project.git
git fetch upstream
git merge upstream/master
git push
git branch featurebranch
git checkout featurebranch
#edit files: file1, file2, file3
git add file1
git add file2
git add file3
git commit -m 'updates for feature'
git push --set-upstream origin featurebranch

Then on github I went to my forked repository, selected Branch: featurebranch, and clicked Pull request. The request includes my merges from synching my fork:

How can I avoid this in the future?

score 7 · Accepted Answer · answered Nov 28 '15 at 02:01

You should just git rebase against the branch that you're issuing your pull request against. For instance:

git rebase origin/master

Since this will change the history of your branch, you are better off doing this rebase in a new branch. So:

git checkout -b new_rebased_branch
git rebase origin/master

For future reference, if you don't want merge commits in your pull requests, you should try to update your branches via rebase rather than merge. Again, I always recommend checking out a separate branch to do this in, since rebasing will change your commit history, you may want to keep a backup of the original commit history.

score 2 · Answer 2 · answered Dec 05 '19 at 20:12

2

Since Dec. 4th 2019, you could try and protect your PR branch and reject any push that contains a merge commit by enabling Require linear history.

That would ensure you are force to use git pull --rebase, because otherwise, you would not be able to push.

answered Dec 05 '19 at 20:12

VonC

1,262,500
529
4,410
5,250

score 1 · Answer 3 · edited May 23 '17 at 12:23

As @mkrufky points out, you should use git rebase to rebase your work onto the master branch. However, it is not necessary to create a new branch, as rebase does not really rewrite the history, but rather "replays" the commits onto the new base. Git even keeps track of all the old commits in the git reflog for a certain time, which prevents you from losing your history that way.

The correct workflow would be:

git fetch origin master
git rebase origin/master

But, that's exactly what git pull --rebase does! It is an option to rebase your work onto the branch you're pulling against instead of doing a merge of the two branches.

You can find more explanations here: Difference between git pull and git pull --rebase and in the Rebasing chapter of the git manual: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Avoiding merge commits in pull requests in git

3 Answers3