请问各位这种情况应该如何拆分代码提交为多个 PR？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 965 天前的主题，其中的信息可能已经有所发展或是发生改变。

假设有 ABC 三个需求，这三个需求需要同一个人开发。

此时开发写好了 ABC 的代码，以 A->B->C 的顺序用 Git 提交至个人分支中。

但 review 代码时，三个需求一起 review 过于痛苦，我们希望有更细粒度的方式。

因此可以有两种提 PR 的方式：

从 master 分支拉出三个需求分支，提出三个 PR，目标分支都为 master ，代码提交分别是：

master
  \ \ \
   \ \ -> A (PR1: A..master)
    \ --> B (PR2: B..master)
     ---> C (PR3: C..master)

从 master 分支只拉出一条分支，但是基于该个人分支再拉分支，最后提出三个 PR，但是目标分支各不一样，提交图如下：

master
      \
       -> A (PR1: A..master)
           \
            -> B (PR2: B..A)
                \
                 -> C (PR3: C..B)

请问各位哪种方法更好呢？

个人担忧：方法一可能会在合并时产生 conflict，方法二对合并顺序有依赖。

7 条回复 • 2021-08-30 06:17:40 +08:00

wzzzx

2021-08-27 22:50:43 +08:00

具体得看这些需求的依赖度.如果没有任何依赖的话肯定是采用方法一, 否则就需要采用方法二.
其次即便是在一个分支里, 我在团队里推行的方法是小步快跑. 就是在分支 A 上再开一个分支 B, 完成一个小节点就 review 合并到 A 里, 最终再合并回主分支

TripleZ

2021-08-27 23:12:29 +08:00

@wzzzx 当真的修改起代码来，可能一开始无法判断是否会造成未来的合并冲突。

根据您的回复，您的团队应该是使用我上文提到的“方法二”，请问我的理解对么？

7gugu

2021-08-28 14:08:24 +08:00

方法一好，冲突起码是可以拉下来解决的，但是方法二的话，很容易因为理不清结构关系，到时候把整个提交记录整成一锅粥。

yohole

2021-08-28 17:03:57 +08:00

方法一好。

因为这不仅仅是合并有依赖问题，而是有可能需求上线的顺序或要求不一样，例如最后只上 AC 或者先上 AC，那么你方法二就会手忙脚乱了；

其实这不就是常见的团队 git 工作流么？一般不同的需求都是需要基于主干开发，然后先上线的先合并回去主干，然后其他人拉主干并解决冲突，如此类推

wzzzx

2021-08-28 17:20:41 +08:00

@TripleZ #2 具体问题具体分析. 我们团队大部分的需求之间都不会有依赖, 所以用的是方法一. 我是在方法一的基础上, 根据团队的情况进行了一点扩展

kwrush

2021-08-29 05:02:31 +08:00

方法一好，我觉得如果有依赖就不该并行开发吧

dayeye2006199

2021-08-30 06:17:40 +08:00

这个和 review 的工具也有关系。

比如你用原装的 github 来 code review，方法二会非常的令人费解。
如果你用 Gerrit，phabricator 这样的工具，方法二也是可以拆的比较清楚的。