有没有一种方法可以“隐藏”在比较分支时合并提交GitHub？ [英] Is there a way to "hide" merge commits in GitHub, when comparing branches?

问题描述

我们有10个左右的团队正在使用GitHub来开发我们的项目。我们有一个主要的开发分支，我们通过它创建特性分支来完成我们的开发任务，然后我们将这些特性分支合并回到 develop 。我们使用Pull Requests来做代码评论。所有标准的东西。

然而，有一件事一直困扰着我。

说开发者A创建一个功能分支名为 myFeature 。在这个分支中，他对单个文件进行单行更改，例如 Loop.java 。

与此同时，100个不相关的提交被其他分支，其他开发者合并为 develop 。

现在，开发人员A推送他的更改并发出拉取请求，他希望确保他的更改能够与最新的 develop 分支一起工作。因此，他将 develop 的HEAD合并到他的分支中：

  git checkout开发
 git pull 
 git checkout myFeature 
 git merge develop 
＃testing and stuff 
 git push origin myFeature 
  

最后一个命令（ git merge develop ）总是会导致新的提交。因此，当开发人员A推送其更改并为 myFeature 发出合并请求时，合并请求审阅者将看到101个提交添加到分支 myFeature ：其中一个变为 Loop.java ，另外100个不相关，实际上已经合并到 develop 。在这里，他们只是用来掩饰这个分支中developerA真正改变了什么。

是否有一种简单的方法让审稿人知道发生了什么变化只是开发人员的A更改，并以某种方式隐藏来自与开发？合并的提交。我特别想到了文件已更改选项卡Pull Request视图。
（我意识到我可以使用Commits选项卡，逐个逐个检查所有提交，看看有什么变化，但是如果提交的提交很多，这可能会很麻烦，我喜欢单数，final ）

编辑： git rebase develop 已被提议作为一种选择，但我认为它不适合我们的目的。通常情况下，多个开发人员将在 myFeature 上工作，因此重写可能会混淆每个人，因为它会重写历史记录。

编辑2 ：正如@kan在下面指出的那样，GitHub实际上表现得很好：是的，它会在合并提交中显示合并提交（这是非常好的），但在文件已更改选项卡下，仅列出在此功能分支上更改的文件（而不是合并中的文件）。这正是我正在寻找的。

解决方案

一种方法不是做 git合并是 git rebase develop 。这不会导致合并提交发生，并将新提交放在开发中的新提交结束。

历史应该只显示一个新的提交为已更改在拉请求中。海事组织这也保持历史相当线性，更容易遵循。

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.

解决方案

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.

这篇关于有没有一种方法可以“隐藏”在比较分支时合并提交GitHub？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！