How to prevent merged changes from appearing as 'changes to be committed'

Question

A second developer and I are working on a feature branch together. We want to test this feature with changes that have been made in the master branch. Normally I might use git rebase master, but this won't work for a few reasons.

• Changes have been pushed to remote and shared with other developers.
• There are merge conflicts with master that would make rebasing complicated and risky.

So I want to merge master into my feature branch to get the changes. However when I merge, the specific changes made on master appear as 'changes to be committed'. I imagine that when I make the pull request to put these changes in master that it will make reviewing the changes messy and hard to follow because of the noise of other peoples' changes.

What's the right way to update a feature branch with changes from master when using git merge without cluttering a pull request with unrelated changes and duplicate commits?

I've hunted around and can't find a good answer to this question since most people recommend rebasing. This seems to be the closest, but its accepted answer has -1 votes, and the others don't actually answer the question.

Answer 1

You're conflating two different things: staged changes (changes to be committed) on the one hand, and pull request change sets on the other.

Pull requests are not a git concept, so how well they calculate their change sets depends on the host service that implements them. The problem you're describing should not occur if the pull request calculates its change sets in a reasonable way. At the git level, when making a pull request from branch to master, you'd want the changes to be calculated as master..branch - which excludes the master commits that were merged in for exactly the same reason it excludes the master commits that already existed when branch was created. I believe github handles this properly.

But as to the other side of your question: the assumption that you don't want the changes to appear as "changes to check in" - or that this is closely related to how a pull request review should look - is misguided. For the merge commit to correctly incorporate the changes from master, they have to be represented in the index, which makes them "changes to be committed".

The only way around that is to not commit the merge at all. Some people recommend that (for similar reasons to why some people recommend constant rebase operations). I disagree with that recommendation (for similar reasons to why I disagree with recommendations for constant rebase operations).

If you do decide not to preserve the merge, you can mitigate (but not eliminate) some of the down-sides of that decision with git rerere, which helps with re-applying any conflict resolutions that might be thrown out when you discard the merge.