这是一个创建于 1612 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前有了 150 个 commit，新增 2800 行代码，删除 300 行代码，预计 200 个 commit 可以完成这个需求。
我们现在的做法是在 develop 分支上开一个 feature 分支进行开发，开发完 review 后合入 develop 。但是现在这个分支太大了些，对 review 非常不友好，对于这种情况，大家是怎么处理的？
 |
1
rrfeng 2020-06-29 23:26:11 +08:00 via Android
一点一点写上去，不要最后一次提交（ review ），没人有耐心看完…
|
 |
2
11ssss 2020-06-30 00:25:56 +08:00
1.需求本身拆分有问题，没有拆分到最小粒度的需求算是没想明白的伪需求吧 建议下次能拆则拆
2.可以把已经做完的 先 review 完合进去，剩下的需求拆分到最小单位一个一个分支做 |
 |
3
cs419 2020-06-30 05:25:33 +08:00
既然已经功能已经实现了，那就再重构下呗
再单独开个分支，逐个单个功能的代码复制过来，逐个测通提交 这个新分支下，你拆分出几个功能，就有几个提交 原先的分支不要了 |
 |
4
nightwitch 2020-06-30 08:36:26 +08:00
都提交了 150 个 commits 了还能说啥。。我比较好奇的是分叉这么多了，还能合并回主线吗
|
 |
5
xuanbg 2020-06-30 08:52:11 +08:00
多拆几个 feature，每个 feature 对应一个 feature 分支。然后大家各写各的 feature 代码，提交的自己对应的 feature 分支就好了。
要注意的是拆分 feature 时不要让代码有交集。如果有公共的代码，提取出来交给专门的人负责，或者在动这部分代码的时候相互打个招呼。 |
 |
6
dany813 2020-06-30 09:37:09 +08:00
这改动有点大啊
|
 |
7
wzzzx OP @11ssss 这里的拆分是开发角度的拆分还是需求角度的拆分？
@cs419 我觉得你这个方法用来解决当前的这个问题确实不错，我今天花点时间拎出来。不过之后的开发流程还得想想办法。 @nightwitch 可以丫，因为需求比较独立，跟其他文件依赖不大。 @xuanbg 我们现在这样的分支管理方式，bug/feature 都会专门开一个分支搞。问题在于有些 feature 比较大，比如我当前的这个，所以我在找一种方式解决这个问题。你这里说的拆分是指需求层面还是开发层面的拆分？ |
Select Language