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

[hanyceZ]

[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 被迫“提测”。请问对于这种情况怎么解决呢