你们 gitlab 多人开发项目是走 fork 还是原始项目新建分支？

[hanyceZ]

[Fule]

@Mystery0, 每人一个 feature 应该是每人工作在各自的 feature branch 上吧，只有完成了当前 feature 才合并或 rebase 代码到 test branch 上，这样才可以确保 test branch 上没有未完成的代码。如果有一个 feature 依赖于另一个 feature 的代码，那么只能把这 2 个 feature 都分配给同一个人或者必须等被依赖的 feature branch 并入 test branch 之后另一个 feature branch 再从 test branch 上得到依赖的代码。

[iosx]

@Mystery0 #20 @Mystery0 #20 我们是个人从 dev 拉分支 feat-dev 开发，确认可以提测了再 mr 到 dev 分支，此时 ci 自动生成测试版本，测试通过且 codereview 通过再确认 mr 。当然前提最好是每个人开发的功能模块是独立的。

[abigeater]

@hanyceZ
@villivateur
刚看到，按我理解分支就是从某个分支用来新增功能或修复 BUG ；开发人员是没有直接提交 master 权限提交 mr 等待被合，正如 villivateur 说，每个分支代表不同的功能点开发或者某个 BUG 的修复（我们也正是这样做）。分支合进了主分支后就删掉远程分支，本地删不删就没所谓了。

另外我的理解 fork 更像是不同人直接的协作，而团队内并不像这样的形式（像楼上说之间功能有依赖关系 fork 更麻烦

[Mystery0]

@Fule 这样其实也可以，但是 leader 说这样就有太多的 feature 分支了，下一季度我尽量往这方面推吧

[Mystery0]

@Fule
@iosx
突然想起来一个事情，这样子岂不是需要大于等于 feature 数量的开发联调环境，目前我司就 3 个环境，一个开发、一个测试、一个预生产，按照 feature 拆分的话，在季度开发前期，开发环境不够用

[zhouxuchen]

@Mystery0 #20 我们仨分支，master 、canary 、develop ，feature 分支能够直接 merge 到 develop ，且能 push ，方便开发测试； master 分支和 canary 分支仅接受 mr ，且 canary 分支仅接受 feature 分支的 mr ，master 仅接受 canary 的 mr ；如果要上 canary 分支就表示这个功能在 develop 上由测试确认可以上线，上了 canary 之后再由产品验收，因为验收一般就跑个冒烟用例，要不了很久，基本不会卡流程；坏处就是 develop 上有大量因为管理层拍脑袋而夭折的需求……

[thevita]

fork 和 feature branch 在这里有太大区别么，不都通过 mr 来合并？,反而更复杂不方便协作。

至于说多人维护同一个 feature 分支的的协作问题，我个人倾向是下 feature 粒度，快速合并，尽量减少这种情况，同时尽量避免长期不能合并的 mr ，当然这更项目架构，团队架构都有关系，就比较复杂了，也一定对，，适合自己的才是最好的。

[DeWhite]

...
开个新分支，然后开发完 rebase 。

[msg7086]

Fork 就是陌生人之间的 feature branch 。一个团队里要什么 fork ，除非是你自己折腾仓库完，正常的开发完全没必要用 fork 。太多的 feature branch 又怎么了，又不收你钱。Merge 以后分支就删了。

[vincent7245]

feature -> dev -> sit -> uat -> master
uat 和 master 的合并都要审核

[vincent7245]

aHR0cHM6Ly93d3cuY25ibG9ncy5jb20vc2NhankvcC8xMTUxNDQzNi5odG1sCg==
这篇博客介绍的很详细

[wannaspring]

@vincent7245 来个链接。。

[itfisher]

@Mystery0 你们是那种大型需求嘛？我们这边都是每个人 feature 分支开发自测没问题，才提交到公共测试分支发布在测试环境（有冲突至少在测试阶段就能知晓了），测试分支没问题再提预发布测试，预发布没问题提 mr 。我理解大部分公司应该都是这个流程吧？

[Mystery0]

@itfisher 一个季度的需求有 20-30 个吧，每个 feature 一个分支的话，太多了

[Fule]

@Mystery0, feature 分支属于“私人分支”，换句话说，人在 feature 分支里玩儿出花来也没关系，它并不参与 CI 过程也不会共享代码给别人，当某个 feature 在 feature 分支完成之后会 rebase 到最新的 test 分支并压缩成唯一提交（如果 feature 分支上有多个提交的话）然后提交 PR 到 Test 分支。一旦 feature 分支合并到了 test 分支，这个 feature 分支就可以删掉了。如果那个 feature 在 test 分支上测试时出现了问题，那么基于最新 test 分支重新创建一个新 feature or bugfix 分支进行处理，并重复之前的过程。

如果出现多个 feature 需要并行共享代码联调，那么我觉得有两种方法：

1. 所有 feature 功能实现划分可能需要优化或细化，变成多阶段处理，每阶段可以无（大量）互相依赖在各自独立开发，然后下一阶段可以依赖前一阶段的代码
2. 多 feature 共享的代码部分可以交予一名主程直接在 test 分支上开发，然后其它各个 feature 分支随时 rebase test 分支。

[Mystery0]

@Fule 但是很多 feature 分支的话，开发环境不够，代码开发可以本地就完成，多数 feature 开发完毕之后需要部署到开发环境和其他服务（前端）联调。你说的 feature 开发，完毕之后合并到 test ，且丢掉原 feature 分支，如果出现问题以 patch 的形式修改，这个感觉可以借鉴一下。

[asuraa]

git-flow 瞭解一下