对于一个很大的需求，分支应该怎么处理

[wzzzx]

目前有了 150 个 commit，新增 2800 行代码，删除 300 行代码，预计 200 个 commit 可以完成这个需求。

我们现在的做法是在 develop 分支上开一个 feature 分支进行开发，开发完 review 后合入 develop 。但是现在这个分支太大了些，对 review 非常不友好，对于这种情况，大家是怎么处理的？

[rrfeng]

一点一点写上去，不要最后一次提交（ review ），没人有耐心看完…

[11ssss]

1.需求本身拆分有问题，没有拆分到最小粒度的需求算是没想明白的伪需求吧 建议下次能拆则拆
2.可以把已经做完的 先 review 完合进去，剩下的需求拆分到最小单位一个一个分支做

[cs419]

既然已经功能已经实现了，那就再重构下呗
再单独开个分支，逐个单个功能的代码复制过来，逐个测通提交
这个新分支下，你拆分出几个功能，就有几个提交
原先的分支不要了

[nightwitch]

都提交了 150 个 commits 了还能说啥。。我比较好奇的是分叉这么多了，还能合并回主线吗

[xuanbg]

多拆几个 feature，每个 feature 对应一个 feature 分支。然后大家各写各的 feature 代码，提交的自己对应的 feature 分支就好了。
要注意的是拆分 feature 时不要让代码有交集。如果有公共的代码，提取出来交给专门的人负责，或者在动这部分代码的时候相互打个招呼。

[dany813]

这改动有点大啊

[wzzzx]

@11ssss 这里的拆分是开发角度的拆分还是需求角度的拆分？
@cs419 我觉得你这个方法用来解决当前的这个问题确实不错，我今天花点时间拎出来。不过之后的开发流程还得想想办法。

@nightwitch 可以丫，因为需求比较独立，跟其他文件依赖不大。

@xuanbg 我们现在这样的分支管理方式，bug/feature 都会专门开一个分支搞。问题在于有些 feature 比较大，比如我当前的这个，所以我在找一种方式解决这个问题。你这里说的拆分是指需求层面还是开发层面的拆分？

[xuanbg]

@wzzzx 当然是拆需求呀，譬如一个大需求拆成 3 个功能，那么建 3 个 feature 分支不就好啦

[11ssss]

@wzzzx 我楼下说了的 从功能和需求角度拆分