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

[abigeater]

原始项目新建分支

[hanyceZ]

@abigeater 我是一直在走 fork 的流程，原始项目禁止提交，只能走 mr 。感觉原始项目新建分支并不如 fork 好啊，可以说下为什么在用吗

[wolfie]

@hanyceZ #2
A B 两人 并行开发，A 依赖 B 未合并功能。Fork 出来的应该怎么处理。

[villivateur]

@wolfie 发起反向的 pr

[hanyceZ]

@wolfie B push 到他 fork 下来的项目上去，A 去 pull B fork 来下的仓库即可

[villivateur]

@abigeater 你这样做的话，分支的意义就不明确了，按理来说，不同分支应该代表不同的开发进度或者功能适配点，而不是每个人都开发进度

[sunny352787]

新建分支，master 分支保护，合并发起 mr 审核

[hanyceZ]

@sunny352787 我觉得这种方式，开发人员变多的话，分支就会很难看，就会有各种各样基于某某某的分支衍生出来，fork 下来的原始项目会稍微干净一些吧

[wolfie]

@villivateur #4
@hanyceZ #5
如果一个项目 10 个人 开发，10 个人 之间都有可能有交际，可能要维护 10 个 remote 。

[Goooler]

都是 maintainer 了还需要 fork 吗，这也太没牌面了吧

[deplivesb]

分支啊，fork 怎么解决 彼此依赖的问题？
我司的有的大型的项目都是几百个分支

[sunny352787]

@hanyceZ 没啥区别，fork 还多了一些操作，想操作别人正在修改的东西也太麻烦了，为了分支洁癖给自己制造障碍没啥必要，该走的分支合并审核 CI 流程走好了就行了

[villivateur]

@wolfie 维护一个主线仓库，其他仓库都往这个主线仓库提 PR 不就行了

[xuanbg]

1 人 1 分支，开发完的合并到 test 分支进行测试。

[timothyye]

fork 不推荐，禁止直接 push 或者 merge 到 master ，每次开发都从 master 新建分支，通过代码 review 之后再 merge 回 master

[CoCoMcRee]

拉一个用于迭代的 test 分支. test 分支设置保护只有 MR 权限, 禁止直接 PUSH.
多人开发就拉取多个 dev 分支.

每次代码提交都按照流程走.
比如 ABC 三人同时开发.
A 今天开发了一点, 先把远端 test 合并到本地 A-dev. 有冲突解决冲突. 然后到 gitlab 上把 A-dev 合并到 test, 同时指派给领导(或自己)进行 CodeReview. 没问题了就同意合并.
同理.
B 或 C 今天开发了一点功能, 也是先把远端 test 合并到本地 B-dev. 有冲突解决冲突. 然后到 gitlab 上把 A-dev 合并到 test, 同时指派给领导(或自己)进行 CodeReview. 没问题了就同意合并.


这样做的好处是, 所有人都在提交代码前要把 test 拉取到本地, 这样就会有其他所有人的代码. 同时需要本地解决冲突. 保证远端代码是不会冲突的. 才能通过 MR 合并到 test 上.

每次要发布测试版都从 test 上发.

[Jwyt]

走 fork 多麻烦啊，这不是给自己找事么

[kidonng]

10L 在理，fork 存在的主要意义是为了让没有 write access 的人能够有地方提交代码，有 write access 的话 fork 是完全没有必要的。

[risky]

既然都 gitlab 了, 为什么不试试 gitlab flow + rebase 呢?

[Mystery0]

@CoCoMcRee 我司最开始也是这么玩的，但是一直以来有一个问题：多人共同对一个项目进行开发，各自负责一个 feature ，所有人都在开发阶段提交代码到 test 上，当其中有一个 feature 提测之后，就需要部署到提测环境，只是直接部署 test 分支就会把其他人还处于开发中的代码一并部署，然后其他人的 feature 被迫“提测”。请问对于这种情况怎么解决呢

[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 瞭解一下