解决冲突并保留原子特性分支

Question

给定以下git工作流：

• 功能分支fb1是从主分支(生产稳定代码库)创建的。
• 当dev完成后，创建一个拉请求，然后将release-branch-1.x.x合并为fb1。
• 另一个特性分支fb2是从主服务器创建的。
• 当dev在release-branch-1.x.x上完成时，将创建另一个拉请求并试图将其合并到fb2中，但由于冲突(很可能是由fb1中的某些代码引入)而失败。

根据文献资料解决冲突的方法，将文献资料(包含fb1代码)本地合并到fb2中，决定保留什么(解决冲突)，然后将fb2推送到远程更新拉请求。

这很好地解决了冲突，但是将关于release-branch-1.x.x的所有工作添加到fb2中，这是我想要避免的。假设我想恢复 fb1 合并提交，那么fb1代码仍然在发布分支上，因为它是由fb2引入的。

对于如何避免这种情况，有什么想法吗？

Answer 1

在大多数工作流中，每个特性分支的所有者负责使其分支与“正式”代码行保持最新(为了尽可能通用，我将调用集成分支母版，尽管它可以在各种工作流中进行开发、发布或其他名称)。因此，场景的完整序列如下所示：

1. Developer 1从主启动fb1
2. Developer 2从主启动fb2
3. Developer 1完成了他的特性，并提交pr1将fb1合并为主。
4. fb1 被测试和批准，pr1被接受，主被更新为包含初始+fb1
5. Developer 2完成了她的功能，但发现她的分支现在已经过时了。
6. Developer 2将主合并到 fb2 中，并解决其分支现在包含初始+ fb1 +fb2的冲突。
7. 开发人员2提交一个pr2将fb2合并为主。
8. 在feature1中发现了一个严重的错误，因此fb1与主的合并将被恢复，主服务器现在只包含初始的
9. fb2现在已过时，因为主已被更改，如果以前已经解决了冲突，则这些冲突将在恢复原始代码时再次发生，因此pr2将无法自动合并，bitbucket将向您发出警告。
10. Developer 2将主合并为 fb2 并解决冲突，使其分支包含初始+fb2。
11. Developer 2推动更新pr2，然后对其进行批准和合并，从而生成一个包含初始+ fb2的主分支。

Git在合并时使用两个提交的最近的共同祖先，而不是代码发散的原始点。即使没有冲突，当将来自主分支(包括 fb1 )的更改集成到fb2中时，这两个分支之间的共同祖先将是包含初始+fb1的主服务器上的一个点，如果随后从主服务器中删除fb1，则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