Question

我的情况如下[这不是一个具体的编程问题，但我预见会很快发生在我身上]

我分配了2张票，需要将2个密切相关的功能（分别为功能1和功能2）添加到工具中。必须有2个单独的提交（或2个不同的提交集）与添加这些功能相关联
添加这两个功能需要编辑大约95％的相同源文件
为实现功能2而需要引入的更改取决于功能1的更改。即if(feature1 flag enabled) foo; else bar;
我刚刚实施了feature1并发出了代码审核，代码审核周转时间约为2-5天。我确定审核人员会建议进行一些更改
然而，当他们正在审核功能1时，我想开始实施功能2

如何以避免/减少痛苦的合并冲突的方式进行此操作？我不想在处理功能1的评论评论的过程中签入/发布与功能2相关的评论内容。

我的团队使用git，使用git flow。

[不是假设的问题，实际问题]

Answer 1

鉴于“需要引入以实现功能2的更改取决于功能1 的更改”，您可以将功能2作为功能1的分支启动。这样，在处理功能2时，您可以单独处理功能1的审阅注释，并开始使用功能1代码已经就位于公共文件中的feature2。

然后，当功能1的审核完成并即将合并时，您可以：

合并功能1（开发，我假设）然后将功能2更改为更新的开发

develop  - - - - - - - - - - - - - - - - - o (merge feature 1)
         \                                / \
feature1  - o - o (for-review) - o (fix) -   \
                 \                            \
feature2          - o - o - o - - - - - - - - -o (rebase) - o (continue)

将功能2更改为功能1的最终提交

develop  - - - - - - - - - - - - - - - - - o (merge feature 1)
         \                                / 
feature1  - o - o (for-review) - o (fix) -   
                 \                \
feature2          - o - o - o - - - o (rebase) - o (continue)

请注意，这不会完全避免冲突。如果feature1的评论注释需要对公共代码进行一些重构或完全重新设计实现，那么重新定义feature2肯定会引入冲突，但至少它本地化在feature2分支中。但是在注释主要是语法的情况下，或者例如添加了错误处理等等，那么rebase应该没有任何问题。

当2次连续提交编辑相同的文件时，避免/最小化git合并冲突

1 个答案: