基于同一文件中的代码的多个拉取请求

Question

我做了很多研究，但仍然有点新奇和困惑。我无法理解这一点，或者可能是我读了很多书，现在我真的很困惑。

场景示例：

我的朋友将我添加为项目的合作者，我必须满足 3 个要求。在同一个文件 abc.txt 中编写函数 A、B 和 C。我从主分支创建了一个新分支。在 abc.txt 中写入我的函数 A 并推送到我的分支。我发起拉取请求并等待审核。

现在这就是我感到困惑的地方。我需要处理同一个文件，需要编写我的函数 B 和 C 并让它们也进行审查，那么最佳方法是什么？

一个是继续对有 PR 待处理的同一个文件进行更改或签出一个新分支？

Answer 1

如果您的进一步工作依赖于函数 A，那么请从旧分支创建一个新分支，并在完成后继续您的工作提出新的拉取请求。

Answer 2

如果 A、B 和 C 都是独立的，那么我认为签出一个新分支，实现 A，为此提交 PR，然后返回 master 分支是有意义的。然后为 B 签出一个新分支，为此提交第二个 PR，然后返回原始分支并再次为 C 重复。因此，在此结束时，在您的任何 PR 被审查之前，您的树可能看起来像

--------o master
        |---------feature_A_branch
        |---------feature_B_branch
        |---------feature_C_branch

这使您可以在每个分支中创建进一步的提交以解决 PR​​ 建议，然后当每个 PR 被接受时，您可以将其压缩合并回 master，这样您就可以在 master 中为每个功能 A 准确地提交一个提交， B 和 C。

当然，这是假设 A、B 和 C 完全不相互依赖

编辑以添加关于 A、B 和 C 何时共享代码的内容：

如果 A、B 和 C 依赖于一些共享代码 S，那么您可以修改上面的代码，以便在完成 A 并在那里创建新分支之后签出 master，而不是在分支带有 { S,A} 仍在 PR 中。这看起来像

---o master
   |
   |----S---feature_A (with commit for the common shared code)
        |---feature_B
        |---feature_C

然后，当 A、B 或 C 中的任何一个首先通过 PR 时（假设 B 为具体），您会将 feature_B 合并回 master，这也会将 S 中的更改带到 master也是。现在，您可以在master 上重新设置feature_A 和feature_C（合并后在S 中进行了更改），因此feature_A 仅对A 进行更改，feature_C 仅对C 进行更改。合并，树可能看起来像：

---o---S---B (master)
           |----feature_A
           |----feature_C