1
abigeater 2021-12-08 17:24:14 +08:00
原始项目新建分支
|
2
hanyceZ OP @abigeater 我是一直在走 fork 的流程,原始项目禁止提交,只能走 mr 。感觉原始项目新建分支并不如 fork 好啊,可以说下为什么在用吗
|
4
villivateur 2021-12-08 17:59:09 +08:00 via Android
@wolfie 发起反向的 pr
|
6
villivateur 2021-12-08 18:04:12 +08:00 via Android
@abigeater 你这样做的话,分支的意义就不明确了,按理来说,不同分支应该代表不同的开发进度或者功能适配点,而不是每个人都开发进度
|
7
sunny352787 2021-12-08 18:04:30 +08:00 4
新建分支,master 分支保护,合并发起 mr 审核
|
8
hanyceZ OP @sunny352787 我觉得这种方式,开发人员变多的话,分支就会很难看,就会有各种各样基于某某某的分支衍生出来,fork 下来的原始项目会稍微干净一些吧
|
9
wolfie 2021-12-08 18:10:29 +08:00
|
10
Goooler 2021-12-08 18:11:39 +08:00
都是 maintainer 了还需要 fork 吗,这也太没牌面了吧
|
11
deplivesb 2021-12-08 18:13:19 +08:00
分支啊,fork 怎么解决 彼此依赖的问题?
我司的有的大型的项目都是几百个分支 |
12
sunny352787 2021-12-08 18:17:14 +08:00
@hanyceZ 没啥区别,fork 还多了一些操作,想操作别人正在修改的东西也太麻烦了,为了分支洁癖给自己制造障碍没啥必要,该走的分支合并审核 CI 流程走好了就行了
|
13
villivateur 2021-12-08 18:29:40 +08:00
@wolfie 维护一个主线仓库,其他仓库都往这个主线仓库提 PR 不就行了
|
14
xuanbg 2021-12-08 18:36:25 +08:00
1 人 1 分支,开发完的合并到 test 分支进行测试。
|
15
timothyye 2021-12-08 18:41:12 +08:00
fork 不推荐,禁止直接 push 或者 merge 到 master ,每次开发都从 master 新建分支,通过代码 review 之后再 merge 回 master
|
16
CoCoMcRee 2021-12-08 18:53:42 +08:00
拉一个用于迭代的 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 上发. |
17
Jwyt 2021-12-08 19:06:32 +08:00
走 fork 多麻烦啊,这不是给自己找事么
|
18
kidonng 2021-12-08 21:57:57 +08:00 via Android 1
10L 在理,fork 存在的主要意义是为了让没有 write access 的人能够有地方提交代码,有 write access 的话 fork 是完全没有必要的。
|
19
risky 2021-12-08 22:32:02 +08:00 1
既然都 gitlab 了, 为什么不试试 gitlab flow + rebase 呢?
|
20
Mystery0 2021-12-09 00:36:06 +08:00 via Android
@CoCoMcRee 我司最开始也是这么玩的,但是一直以来有一个问题:多人共同对一个项目进行开发,各自负责一个 feature ,所有人都在开发阶段提交代码到 test 上,当其中有一个 feature 提测之后,就需要部署到提测环境,只是直接部署 test 分支就会把其他人还处于开发中的代码一并部署,然后其他人的 feature 被迫“提测”。请问对于这种情况怎么解决呢
|
21
Fule 2021-12-09 08:58:55 +08:00
@Mystery0, 每人一个 feature 应该是每人工作在各自的 feature branch 上吧,只有完成了当前 feature 才合并或 rebase 代码到 test branch 上,这样才可以确保 test branch 上没有未完成的代码。如果有一个 feature 依赖于另一个 feature 的代码,那么只能把这 2 个 feature 都分配给同一个人或者必须等被依赖的 feature branch 并入 test branch 之后另一个 feature branch 再从 test branch 上得到依赖的代码。
|
22
iosx 2021-12-09 09:13:58 +08:00 via iPhone
|
23
abigeater 2021-12-09 09:25:55 +08:00
@hanyceZ
@villivateur 刚看到,按我理解分支就是从某个分支用来新增功能或修复 BUG ;开发人员是没有直接提交 master 权限提交 mr 等待被合,正如 villivateur 说,每个分支代表不同的功能点开发或者某个 BUG 的修复(我们也正是这样做)。分支合进了主分支后就删掉远程分支,本地删不删就没所谓了。 另外我的理解 fork 更像是不同人直接的协作,而团队内并不像这样的形式(像楼上说之间功能有依赖关系 fork 更麻烦 |
25
Mystery0 2021-12-09 10:12:37 +08:00
|
26
zhouxuchen 2021-12-09 10:22:48 +08:00
@Mystery0 #20 我们仨分支,master 、canary 、develop ,feature 分支能够直接 merge 到 develop ,且能 push ,方便开发测试; master 分支和 canary 分支仅接受 mr ,且 canary 分支仅接受 feature 分支的 mr ,master 仅接受 canary 的 mr ;如果要上 canary 分支就表示这个功能在 develop 上由测试确认可以上线,上了 canary 之后再由产品验收,因为验收一般就跑个冒烟用例,要不了很久,基本不会卡流程;坏处就是 develop 上有大量因为管理层拍脑袋而夭折的需求……
|
27
thevita 2021-12-09 11:32:22 +08:00
fork 和 feature branch 在这里有太大区别么,不都通过 mr 来合并?,反而更复杂不方便协作。
至于说多人维护同一个 feature 分支的的协作问题,我个人倾向是下 feature 粒度,快速合并,尽量减少这种情况,同时尽量避免长期不能合并的 mr ,当然这更项目架构,团队架构都有关系,就比较复杂了,也一定对,,适合自己的才是最好的。 |
28
DeWhite 2021-12-09 12:20:56 +08:00 via iPhone
...
开个新分支,然后开发完 rebase 。 |
29
msg7086 2021-12-09 13:38:23 +08:00 1
Fork 就是陌生人之间的 feature branch 。一个团队里要什么 fork ,除非是你自己折腾仓库完,正常的开发完全没必要用 fork 。太多的 feature branch 又怎么了,又不收你钱。Merge 以后分支就删了。
|
30
vincent7245 2021-12-09 14:34:51 +08:00
feature -> dev -> sit -> uat -> master
uat 和 master 的合并都要审核 |
31
vincent7245 2021-12-09 14:36:31 +08:00
aHR0cHM6Ly93d3cuY25ibG9ncy5jb20vc2NhankvcC8xMTUxNDQzNi5odG1sCg==
这篇博客介绍的很详细 |
32
wannaspring 2021-12-09 14:38:26 +08:00
@vincent7245 来个链接。。
|
33
itfisher 2021-12-09 17:07:17 +08:00
@Mystery0 你们是那种大型需求嘛?我们这边都是每个人 feature 分支开发自测没问题,才提交到公共测试分支发布在测试环境(有冲突至少在测试阶段就能知晓了),测试分支没问题再提预发布测试,预发布没问题提 mr 。我理解大部分公司应该都是这个流程吧?
|
34
Mystery0 2021-12-09 18:38:57 +08:00 via Android
@itfisher 一个季度的需求有 20-30 个吧,每个 feature 一个分支的话,太多了
|
35
Fule 2021-12-09 19:52:59 +08:00
@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 分支。 |
36
Mystery0 2021-12-09 22:00:29 +08:00 via Android
@Fule 但是很多 feature 分支的话,开发环境不够,代码开发可以本地就完成,多数 feature 开发完毕之后需要部署到开发环境和其他服务(前端)联调。你说的 feature 开发,完毕之后合并到 test ,且丢掉原 feature 分支,如果出现问题以 patch 的形式修改,这个感觉可以借鉴一下。
|
37
asuraa 2021-12-10 13:40:07 +08:00
git-flow 瞭解一下
|