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

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

我被分配了两张票证，需要向一个工具添加两个密切相关的功能，分别是功能1和功能2。必须有两个单独的提交或两个不同的提交集与这些功能的添加相关联 添加这两个功能需要编辑大约95%的相同源文件 实现功能2需要引入的更改取决于功能1的更改。i、 e启用iffeature1标志的foo；埃尔斯酒吧； 我刚刚实现了feature1并发送了一个代码评审，代码评审的周期大约是2-5天。我相信评审员会建议一些更改 然而，在他们回顾功能1时，我想开始实现功能2 我将如何以避免/最小化痛苦的合并冲突的方式进行此操作？在处理功能1的评论的过程中，我不想签入/发布与功能2相关的评论内容

我的团队使用git，使用git流

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

鉴于实现功能2需要引入的更改取决于功能1的更改，您可以将功能2作为功能1的一个分支启动。这样，在处理功能2时，您可以将功能1的审阅注释的地址分开，然后开始处理功能2，并且功能1代码已经在公共文件中

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

将功能1合并到开发中，我假设然后将功能2重新设置到更新的开发中 将功能2重设为功能1的最终提交 请注意，这不会完全避免冲突。如果feature1的评审意见需要对公共代码进行一些重构或对实现进行彻底的重新设计，那么对feature2重新定基肯定会带来冲突，但至少它是在feature2分支中本地化的。但是，如果注释主要是语法性的，或者例如添加了错误处理等，那么重基不应该有任何问题

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

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