导致 master 上已有的一堆提交从功能分支推送到拉取请求的 git 问题是什么

Question

我经常在拉取请求中看到这种情况，有人不小心将一堆重新调整的提交推送到他们的 PR 中，然后在“提交”选项卡中，有一长串已经在 master 上的所有现有提交。

我记得当我还是一个 git 新手时，我遇到了这个问题，并且搞乱了 rebase（我不认为合并时存在这个问题），但我不记得是什么导致了这个问题。有谁知道我指的是什么吗？

Answer 1

我有时也会看到这种情况，以下是一些常见原因：

1. 当有人从一个共享分支（例如

   develop

   ）分支出来，并在另一个共享分支（例如

   master

   或

   release

   ）中创建 PR 并创建 PR 时，该 PR 的初始视图通常会变为显示的提交远远多于应有的提交。如果他们随后尝试通过变基来解决此问题（可能使用

   rebase --onto

   ，结果很糟糕），他们可能会意外地重写其分支上已经位于共享分支上的许多提交。
2. 当某个功能分支存在冲突或者您只想使用最新的

   master

   进行更新时，您可以选择将功能分支重新设置为最新版本的

   master

   。但是，如果您不小心将

   master

   的本地副本重新设置为

   feature

   分支，您将重写错误的分支，并且某些 UI 工具可以轻松单击此选项。此时，确实需要执行额外的步骤来将这些提交放入功能分支，但不知何故，新手也往往会意外地执行此操作，可能是通过将该分支合并到其功能分支中，或者然后转身并将其功能分支重新设置为基础新重写了

   master

   。
3. 在重写自己的分支时，也许以交互方式压缩或更新本地提交，有时人们喜欢使用父语法，例如

   git rebase HEAD~10

   来重写其分支上的最后 10 次提交。通常，第 11 次提交是合并提交，从创建分支时完成的最后一个 PR 到

   master

   。因此，如果您不小心返回 1 提交到较远的位置，例如

   git rebase HEAD~11

   ，那么您最终将重新调整 10 个提交以及由第 11 个合并提交引入的

   master

   上的所有提交。然后所有这些提交也会显示在 PR 中。

有助于防止这种情况的可能提示：

1. 我们使用变基工作流程，我们敦促开发人员尽早且经常提交，但也要在创建（或至少完成）他们的拉取请求之前清理它们并进行最少数量的“有用”提交。我们设置了一个门控签入，如果 PR 中有超过 5 个新提交，则该签入将会失败，并且只有不到 1% 的 Pull 请求需要手动干预，因为开发人员希望拥有更多。绝大多数情况下，当某人在 PR 中提交超过 5 次时，这是由于上述问题之一造成的，并且由于网关失败，迫使他们注意到问题并修复它。 我们敦促人们不要查看
master
2. 的本地副本，而应始终获取并使用

   origin/master

   。这几乎消除了#2 的可能性，并且还减少了由于人们意外地基于

   master

   的旧本地副本创建新作品而导致的冲突。