应用错误收集

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

回购在GitHub上托管。

工作流程通常如下：

非常标准。当我们有时遇到测试分支的pull请求时，在pull请求中，github会显示更多提交，这些提交应该由开发人员完成。经过调查，我们已经意识到至少有一个特定情况（可能不是唯一的情况）：

开发人员A对测试进行了一些更改，通过了QA和UA，并与主人合并。
开发人员B进行了一些更改。与master合并时，存在冲突。开发人员B解决冲突并在新的提交中提交修复冲突，例如id为1234567
开发人员A开始工作到另一张票：他从master获取（因此拉动1234567提交），创建分支，提交，推送以及在GitHub上执行pull请求以将其分支合并到测试中时GitHub想要合并其提交加上1234567.这让他很害怕，因为他对这个特定的提交一无所知。

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

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

肯定这一定发生在你之前。你是如何处理它的？

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

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

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

使用gitk或类似方法围绕其中一个问题可视化所有分支，并检查时间戳和审核会议时间，看看是否是隐藏的死区。