Is there a way to "hide" merge commits in GitHub, when comparing branches? [closed]

Question

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.

Closed 8 years ago.

My team of 10 or so are using GitHub for our development project. We have a main develop branch from which we create feature branches to do our development tasks, and then we merge the feature branches back to develop. We use Pull Requests to do code reviews. All standard stuff.

However, one thing has been bothering me.

Say developer A creates a feature branch named myFeature. In this branch, he makes a one-line change to a single file, say Loop.java.

In the meantime, 100 unrelated commits are merged to develop from other branches, by other developers.

Now, before developer A pushes his changes and issues a pull request, he wants to make sure his changes work with the latest develop branch. Thus, he merges the HEAD of develop into his branch:

git checkout develop
git pull
git checkout myFeature
git merge develop
# testing and stuff
git push origin myFeature

The last command (git merge develop) always results in a new commit. Thus, when developer A pushes his changes and issues a Pull Request for myFeature, the reviewer of the Pull Request will see 101 commits added to branch myFeature: one has the change to Loop.java, and the other 100 are unrelated and have already in fact been merged in develop. Here they only serve as noise to disguise what was really changed by developerA in this branch.

Is there an easy way for the reviewer to tell what was changed by just developer's A changes, and somehow "hide" the commits that came from the merge with develop? I'm specifically thinking about the "Files Changed" tab in the Pull Request view. (I realize that I could use the "Commits" tab, and step through all the commits one by one to see what was changed, but this can be tiresome if there are lots of commits. I like the singular, final view of the "Files Changed" tab.)

EDIT: git rebase develop has been proposed as an option, but I don't think it's appropriate for our purposes. Often, multiple developers will be working on myFeature, so rebase has the potential to mess everyone up since it rewrites the history.

EDIT 2: As @kan kindly pointed out below, GitHub is actually behaving nicely: yes, it will show the merge commit in the "Commits" tab of the Pull Request (which is perfectly fine), but under the "Files Changed" tab, only the files changed on this feature branch (and not those from the merge) are listed. This is exactly what I'm looking for.

Answer 1

One method would be rather than doing git merge is to git rebase develop. This will not cause the merge commit to occur and place the new commit at the end of new commits in develop.

The histories should then only show the one new commit as changed in the pull request. IMO this also keeps the history pretty linear and easier to follow.

Answer 2

Yes, you could do it with rebase.

git checkout myFeature
git fetch
git rebase origin/develop
git checkout develop
git merge @{upstream}
git merge myFeature # it will do fast-forward, so no merge commit

However, you should be aware, that rebase should be only used if the myFeature is not shared between other developers.

BTW, we are using gerrit. It allows to rebase a changeset before merging. Of course if works only if there are no conflicts, if there are, you should do rebase locally and resubmit the changeset.