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

我的团队有10人左右正在使用GitHub来开发项目。我们有一个主要的develop分支，我们从中创建特征分支来完成我们的开发任务，然后我们将特征分支合并回develop。我们使用Pull Requests来做代码评论。所有标准的东西。有没有办法在比较分支时“隐藏”GitHub中的合并提交？

但是，有一件事一直困扰着我。

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

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

现在，在开发者A推送他的更改并发出拉取请求之前，他想确保他的更改能够与最新的develop分支一起工作。因此，他融合了develop的头伸进他的分支：

git checkout develop 
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更改所发生的变化，并以某种方式“隐藏”与develop合并产生的提交？我正在考虑合并请求视图中的“文件已更改”选项卡。（我意识到我可以使用“提交”选项卡，并逐个逐个检查所有提交，以查看发生了什么变化，但是如果提交的提交很多，这可能会令人厌烦，我喜欢单独的最终视图“文件已更改”选项卡）。

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

编辑2：由于@kan好心指出下面，GitHub的实际表现很好：是的，它会显示在合并中的“提交”拉入请求的标签（这是完全正常的）承诺，但在在“文件已更改”选项卡中，仅列出在此功能分支上更改的文件（而不是合并中的文件）。这正是我正在寻找的。

来源

2013-05-01 stepthom

如果A的'myFeature'分支从'develop'分支出来，并且他从'develop'中最新的更改合并，我认为GitHub中不应该出现数百个额外的提交，我认为它应该只是提交这是该分支独有的。 A是否将一个pull请求放入错误的分支，比如进入'master'而不是develop？ – 2013-05-02 03:37:05

@ColdHawaiian：不，A从'develop'分支，然后合并'develop'，然后做一个pull请求合并到'develop'。这就是为什么我也很困惑。 – stepthom 2013-05-02 12:01:55

另一种可能性是A的开发历史版本已经被修改过（即在相应的提交中commit shas是不同的）。也许A的提交已经被重写了'rebase'，'cherry-pick'或'commit --amend'？是从命令行使用Git，还是像GitHub for Windows一样的GUI？ Windows的GitHub隐含地使用重新绑定确实很奇怪。 – 2013-05-02 16:02:29

一种方法是，而不是做git merge是git rebase develop。这不会导致合并提交发生，并将新提交放置在新提交结束时进行开发。

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

来源

2013-05-01 21:03:15 Schleis

从我读过的内容（包括下面的@kan）中可以看出，如果功能分支已经被推送到远程服务器，那么'git rebase'不是一个好主意，因为其他开发者也可能已经拉到了分支。真的吗？另外，rebase如何处理合并冲突？ – stepthom 2013-05-02 12:04:06

是的，这是事实。这将重写已推出的历史。 rebase工作的方式是git回滚到分支已经分散的位置，从远程引入更改并逐个应用回滚提交。所以当发生冲突时，您将在继续之前修改提交。由于历史的这种变化，你想要小心一点。 – Schleis 2013-05-02 13:06:32

@ doofuslarge是的，它基本上意味着所有得到分支的开发者也应该进行rebase。如果你仔细阅读'git help rebase'，他们会将其描述为“涟漪效应”。 gerrit引入了变更集的概念，允许以更优雅的方式处理变更集。 – kan 2013-05-02 13:26:27

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

来源

2013-05-01 21:06:48 kan

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

回答

相关问题