Question

我的10人左右的团队正在使用GitHub进行开发项目。我们有一个主develop分支，我们从中创建功能分支来执行开发任务，然后我们将功能分支合并回develop。我们使用Pull Requests进行代码审查。所有标准的东西。

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

假设开发人员A创建了一个名为myFeature的功能分支。在这个分支中，他对单个文件进行了一行更改，比如Loop.java。

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

现在，在开发人员A推送他的更改并发出拉取请求之前，他希望确保他的更改适用于最新的develop分支。因此，他将develop的HEAD合并到他的分支中：

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

最后一个命令（git merge develop）总是会导致新的提交。因此，当开发人员A推送他的更改并发出myFeature的Pull请求时，Pull Request的审阅者将看到向分支myFeature添加了101个提交：其中一个更改为Loop.java，和其他100个无关，实际上已经在develop中合并。在这里，它们只是作为噪声来掩盖开发者A在这个分支中真正改变的内容。

评论者是否有一种简单的方法可以告诉开发人员的A更改改变了什么，并以某种方式“隐藏”与develop合并后的提交？我'我专门考虑了Pull Request视图中的“Files Changed”选项卡。（我意识到我可以使用“提交”选项卡，逐个执行所有提交以查看更改的内容，但如果有很多提交，这可能会很烦人。我喜欢单数，最后的视图“文件已更改“标签。”

编辑：git rebase develop已被提议作为选项，但我认为这不适合我们的目的。通常情况下，多个开发人员将在myFeature上工作，因此，重写因为重写历史记录，所以每个人都有可能弄乱所有人。

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

Answer 1

一种方法是git merge而不是git rebase develop。这不会导致合并提交发生，并将新提交放在develop中新提交的末尾。

然后，历史记录应仅显示在pull请求中更改的一个新提交。 IMO这也使历史保持线性，更容易遵循。

Answer 2

是的，你可以用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

但是，您应该知道，只有在其他开发人员之间不共享myFeature时才应使用rebase。

顺便说一句，我们正在使用gerrit。在合并之前允许rebase a changeset。当然，如果只有在没有冲突的情况下才有效，那么你应该在本地进行rebase并重新提交变更集。

在比较分支时，有没有办法在GitHub中“隐藏”合并提交？

2 个答案: