Is there a way to "hide" merge commands on GitHub when comparing branches?

Question

My team of 10 or so uses GitHub for our development project. We have the main develop branch, from which we create function branches to complete our development tasks, and then merge the function branches back into develop . We use Pull Requests to view the code. All standard materials.

However, one thing bothered me.

Let's say developer A creates a branch named myFeature . In this thread, it makes a one-line change for a single file, for example Loop.java .

Meanwhile, 100 unrelated commits are merged into develop from other branches by other developers.

Now, before developer A pushes his changes and issues a transfer request, he wants to make sure that his changes work with the last develop branch. Thus, it merges HEAD develop into its 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 leads to 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 that 101 commits are added to the myFeature branch: one has a change to Loop.java , and the remaining 100 are not connected and actually were already merged into develop . Here they serve only as a noise to mask what was really changed by the developer in this thread.

Is there an easy way for the reviewer to tell what has been changed only by changes in developer A and somehow “hide” the commits that came from the merge using develop ? I'm specifically thinking about the Modified Files tab in the Request Request view. (I understand that I could use the “Commits” tab and execute all the commits every step to see what has been changed, but it can be tedious if there are many commits. I like the only, final view on “Files changed.” )

EDIT : git rebase develop was suggested as an option, but I don't think it is suitable for our purposes. Often several developers will work on myFeature , so rebase has the potential to beat everyone as it overwrites the story.

EDIT 2 . As @kan kindly noted, GitHub really behaves well: yes, it will show the merge commit on the “Records” tab of the Pull request (which is fine), but on the “Modified files” tab only files modified in this property branch are listed (not merger). This is exactly what I am looking for.

Answer 1

One method would be faster than doing git merge - git rebase develop . This will not result in a merge commit and put a new commit at the end of new commits in development.

Stories should only show one new post, modified in a stretch request. IMO this also keeps the story pretty linear and easier to follow.

Answer 2

Yes, you can do this 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 only be used if myFeature is not shared by other developers.

By the way, we use gerrit. It allows you to update a set of changes before merging. Of course, if it works only in the absence of conflicts, if there is one, you should perform a local reboot and resubmit the changeset.