Github 工作流程和拉取请求显示不需要的提交

Question

在我们的业务中，我们有以下设置（非常简化的版本），非常标准：

• master 分支，通过钩子更新实时环境。
• 一个测试分支，用于 QA、UA，以同样的方式更新测试环境。

repo 托管在 GitHub 上。

工作流程通常如下：

• 从主服务器拉取
• 创建一个分支，例如Ticket1 处理特定的工单
• 工作，本地测试
• 提交并推送分支 Ticket1
• 通过 github 中的 pull request 将 Ticket1 合并到测试中，这样我们就可以进行同行代码审查等。

也很标准。在向我们遇到的测试分支发出拉取请求时，有时在拉取请求中，github 显示的提交比应该由开发人员完成的提交更多。经过调查，我们发现至少有一个特殊情况（可能不是唯一一个）发生这种情况：

1. 开发人员 A 进行了一些更改以测试、通过 QA 和 UA，并将它们与 master 合并。
2. 开发人员 B 进行了更多更改。与master合并时，有冲突。开发人员 B 解决了冲突，并在具有 id 的新提交中提交了对冲突的修复，例如1234567
3. 开发人员 A 开始处理另一个工单：他从 master 拉取（因此拉取 1234567 提交），创建一个分支，提交，推送，当在 GitHub 上发出拉取请求以将他的分支合并到测试时，GitHub 想要合并其提交加上 1234567。这让他很害怕，因为他对那个特定的提交一无所知。

我搜索过类似的问题，至少找到了：

• Why does my GitHub pull request have two commits?
• How to do a pull request in GitHub with only the latest commit in the master branch of my forked repository
• Send a pull request on GitHub for only latest commit

他们处理的是命令行解决方案（基本上使用'rebase'）。但是他们没有为我们解决根本问题，那就是如何避免这种情况发生。我想知道为什么会发生这种情况，也就是说，我们知道何时会发生这种情况，但我们不知道是因为我们的工作流程存在根本性缺陷，还是因为我们遗漏了一些关于如何github 创建拉取请求。

这肯定发生在你之前。你是怎么处理的？

Answer 1

我猜你有一个程序“锁定”问题，并且各个工单分支的起点及其合并点在拉点和最终合并和修复点之间已经重叠。

开发人员认为他们已经在拉取请求中完成了 ticket1，但实际上不应该在合并和修复 [几小时/几天后？] 之前启动 ticket2 的分支。否则，修复程序实际上不会在ticket2 开始时显示。然后当ticket2被拉出来时，它仍然没有修复，所以看起来需要重新应用。

假设您想要一个线性序列的工单合并循环，开发人员需要重新获取 master（包含所有同意的修复程序！），并在他们发出拉取请求之前执行 rebase。

使用 gitk 或类似工具来可视化您围绕这些问题之一的所有分支，并检查时间戳和您的审查会议时间，看看这是否是隐藏的死区。