在共享项目的相同文件上创建多个功能的最佳 git 工作流程？

Question

我正在将一个 2000 行的方法从 A 类重构为 B 类中的几个较小的方法。因此，A 类将大块代码替换为对 B 类中定义的方法的单行调用。B 类不断被附加到，因为我一直在为它编写新方法。到目前为止，我的方法是为我在 B 类中编写并在 A 类中实现的每 3 个新方法创建一个新功能分支。我知道有两个工作流程：

---

工作流程 1：

1. i) 从 dev 创建一个 ft1 分支：stage -> commit -> push -> submit pull request -> 合并到开发中。

   ii) 从 dev 创建一个 ft2 分支：stage -> commit -> push -> submit pull request -> 合并到开发中。

   .

   .

   .

   n) 从 dev 中创建一个 ft(n) 分支。 . .合并到开发中

---

工作流程 2：

1. i) 从 dev 创建一个 ft1 分支：stage -> commit -> push -> submit pull request -> 合并到开发中。

   ii) 从 ft1 创建一个 ft2 分支：stage -> commit -> push -> submit pull request -> 合并到开发中。

   .

   .

   .

   n) 从 ft(n - 1) 创建一个 ft(n) 分支。 . .合并到开发中

---

请记住，从提交 PR 到合并到 dev 之间的时间是可变的，有时很长。我在工作流 1 中看到的问题是我不断覆盖 B 类文件末尾的同一区域。这将导致需要手动解决的合并冲突。工作流 2 的问题在于，从不相关的特征中分支特征没有逻辑意义。当然，所有功能都会影响相同的 2 个文件，但除此之外它们是独立的。现在，如果我在这里错了，请纠正我，但工作流 2 的好处似乎是，如果我总是拒绝为特定功能提交 PR，直到直接在它合并到开发之前出现的功能，那么就不会有用这种方法合并冲突。我在这个评估中是否正确？

哪种工作流程更高效？

Answer 1

工作流程 2 规定了 PR 的顺序，如果

• 存在一些问题，例如代码审查中的问题，您需要在合并之前解决这些问题
• 有多个团队致力于合并 PR，因为工作流 2 一次只允许提交一个 PR

我认为必须解决一些冲突的缺点不太重要，因为每个冲突都应该可以轻松解决：“使用两个文本块，在 FT 之前使用 DEV”。