1

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

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

该存储库托管在 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。这让他感到害怕，因为他对那个特定的提交一无所知。

我搜索了类似的问题，我至少发现：

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

当然，这一定发生在你之前。你如何解决？

4

1 回答 1

1

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

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

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

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

于 2012-08-09T20:55:55.080 回答