这是一个创建于 1079 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
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 瞭解一下
|
Select Language