bitbucket - 解决冲突并保留原子特征分支
bitbucket - solve conflicts and preserve atomic feature branches
鉴于以下 git 工作流程：
- 功能分支 fb1 从 master 分支（生产稳定代码库）创建
- 当开发完成后，创建了拉取请求，然后 fb1 被合并到 release-branch-1.x.x
- 另一个功能分支 fb2 从 master
创建
- 当在 fb2 上完成开发时，创建了另一个拉取请求并试图合并到 release-branch-1.x.x 但由于冲突而失败（很可能由 fb1 中的某些代码引入）
根据the documentation解决这个冲突意味着release-branch-1.x.x（其中包含fb1代码) 在本地合并到 fb2 中，决定保留什么（解决冲突），然后将 fb2 推送到远程以更新拉取请求。
这很好地解决了冲突，但是将 release-branch-1.x.x 上的所有工作添加到 fb2 中是我想避免的事情。假设我想还原 fb1 合并提交，fb1 代码仍将在发布分支上，因为它是由 引入的fb2。
关于如何避免这种情况有什么想法吗？
在大多数工作流中，每个功能分支的所有者负责使他们的分支与 "official" 行代码保持同步（为了尽可能通用，我将调用集成branch master，尽管在各种工作流程中它可以是 develop、release 或其他名称）。因此，您的方案的完整序列如下所示：
- 开发人员 1 从 master
开始 fb1
- 开发人员 2 从 master
开始 fb2
- 开发者1完成他的功能并提交pr1合并fb1到master
- fb1 被测试和批准，pr1 被接受，master 更新为包含初始+fb1
- 开发人员 2 完成了她的功能，但发现她的分支现在已过时
- 开发人员 2 将 master 合并到 fb2 并解决了冲突，她的分支现在包含 initial + fb1 + fb2
- 开发者2提交一个pr2合并fb2到master
- 发现 feature1 导致的严重错误，因此恢复 fb1 到 master 的合并，master 现在包含 初始仅
- fb2 现在已经过时了，因为 master 已经被改变了，如果以前解决了冲突，它们会再次发生恢复原始代码，这样 pr2 将无法自动合并，bitbucket 会警告你。
- 开发者 2 将 master 合并到 fb2 并解决冲突，使她的分支包含 initial + fb2
- 开发人员 2 推动更新 pr2，然后批准并合并，导致包含 的 master 分支初始 + fb2
Git 在合并时使用两个提交的最近共同祖先，而不是代码分歧的原始点。即使没有冲突，当 master 包括 fb1 的更改被集成到 fb2 时，这两个分支之间的共同祖先将是 master 上的一个点，包含 initial + fb1，如果 fb1 随后从 master 中删除，git 会看到这些更改发生在主分支上，并且生成的合并将不包含这些更改。
您可以从代数上考虑合并，其中 m = merge、b = base、l = left、r = right、f = feature 和 i = initial
m = b + diff(b,l) + diff(b,r)
m = (i + f1) + diff((i + f1), (i)) + diff((i + f1), (i + f1 + f2))
m = (i + f1) + (-f1) + (f2)
m = i + (f1 + -f1) + (f2)
m = i + f2
鉴于以下 git 工作流程：
- 功能分支 fb1 从 master 分支（生产稳定代码库）创建
- 当开发完成后，创建了拉取请求，然后 fb1 被合并到 release-branch-1.x.x
- 另一个功能分支 fb2 从 master 创建
- 当在 fb2 上完成开发时，创建了另一个拉取请求并试图合并到 release-branch-1.x.x 但由于冲突而失败（很可能由 fb1 中的某些代码引入）
根据the documentation解决这个冲突意味着release-branch-1.x.x（其中包含fb1代码) 在本地合并到 fb2 中，决定保留什么（解决冲突），然后将 fb2 推送到远程以更新拉取请求。
这很好地解决了冲突，但是将 release-branch-1.x.x 上的所有工作添加到 fb2 中是我想避免的事情。假设我想还原 fb1 合并提交，fb1 代码仍将在发布分支上，因为它是由 引入的fb2。
关于如何避免这种情况有什么想法吗？
在大多数工作流中，每个功能分支的所有者负责使他们的分支与 "official" 行代码保持同步（为了尽可能通用，我将调用集成branch master，尽管在各种工作流程中它可以是 develop、release 或其他名称）。因此，您的方案的完整序列如下所示：
- 开发人员 1 从 master 开始 fb1
- 开发人员 2 从 master 开始 fb2
- 开发者1完成他的功能并提交pr1合并fb1到master
- fb1 被测试和批准，pr1 被接受，master 更新为包含初始+fb1
- 开发人员 2 完成了她的功能，但发现她的分支现在已过时
- 开发人员 2 将 master 合并到 fb2 并解决了冲突，她的分支现在包含 initial + fb1 + fb2
- 开发者2提交一个pr2合并fb2到master
- 发现 feature1 导致的严重错误，因此恢复 fb1 到 master 的合并，master 现在包含 初始仅
- fb2 现在已经过时了，因为 master 已经被改变了，如果以前解决了冲突，它们会再次发生恢复原始代码，这样 pr2 将无法自动合并，bitbucket 会警告你。
- 开发者 2 将 master 合并到 fb2 并解决冲突，使她的分支包含 initial + fb2
- 开发人员 2 推动更新 pr2，然后批准并合并，导致包含 的 master 分支初始 + fb2
Git 在合并时使用两个提交的最近共同祖先，而不是代码分歧的原始点。即使没有冲突，当 master 包括 fb1 的更改被集成到 fb2 时，这两个分支之间的共同祖先将是 master 上的一个点，包含 initial + fb1，如果 fb1 随后从 master 中删除，git 会看到这些更改发生在主分支上，并且生成的合并将不包含这些更改。
您可以从代数上考虑合并，其中 m = merge、b = base、l = left、r = right、f = feature 和 i = initial
m = b + diff(b,l) + diff(b,r)
m = (i + f1) + diff((i + f1), (i)) + diff((i + f1), (i + f1 + f2))
m = (i + f1) + (-f1) + (f2)
m = i + (f1 + -f1) + (f2)
m = i + f2