10

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

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

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

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

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

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

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

审阅者是否有一种简单的方法可以告诉开发人员的 A 更改更改了什么，并以某种方式“隐藏”来自合并的提交develop？我特别考虑了拉取请求视图中的“文件已更改”选项卡。（我意识到我可以使用“提交”选项卡，并逐个查看所有提交以查看更改的内容，但是如果有很多提交，这可能会令人厌烦。我喜欢“文件已更改”选项卡。）

编辑：git rebase develop已被提议作为一种选择，但我认为它不适合我们的目的。通常，会有多个开发人员在工作myFeature，所以 rebase 有可能把每个人都搞砸，因为它重写了历史。

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

4

2 回答 2

7

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

然后，历史记录应该只显示在拉取请求中更改的一个新提交。IMO 这也使历史保持线性且更易于遵循。

于 2013-05-01T21:03:15.083 回答
1

是的，你可以用 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 并重新提交变更集。

于 2013-05-01T21:06:48.073 回答