1
sadfQED2 2022-04-21 11:19:36 +08:00 via Android
第一次见到有 fork 到个人仓这种流程😂直接在主仓建 dev 分支有啥问题吗?
|
2
jasondennis12139 OP @sadfQED2 在主仓每人都建一个 dev 分支?二三十个个人的 dev 分支很难管理啊
|
3
sadfQED2 2022-04-21 11:31:13 +08:00 via Android
@jasondennis12139 为啥难管理,你们要管理啥?我们项目都是上千个分支啊
主仓库 release 分支是线上代码 Master 分支是待上线代码 Test 是测试代码 这三个分支开启 merge 保护,不能随意合代码进去,其他分支都随便玩 |
4
ccyu220 2022-04-21 11:31:38 +08:00
@jasondennis12139
个人认为:公司项目就不需要像 GitHub 上那样先 fork 再分支的流程。 如同 1# 说的一样,每个功能在主仓建立一个分支,开发根据需求再自己本地分支就好了。 如果有公共文件修改,那就再分支一个需求,merge 之后各人再拉取。 dev 全部开发合并完成之后主分支再按版本合并。 --- 综上,不知是否有我还未认知的利弊?我也想学习下其他人的流程是如何。 |
5
sadfQED2 2022-04-21 11:32:02 +08:00 via Android
我们是主仓每个需求建一个分支
|
6
MoYi123 2022-04-21 11:32:52 +08:00
@jasondennis12139 分支肯定不是按人建, 而是按功能建啊.
|
7
Jooooooooo 2022-04-21 11:51:53 +08:00
组内互相了解大家的需求大致的改动啊, 如果有改动同一处功能得提前沟通.
不过你们啥东西需要开发 3 个月? 拆小分开上呗. |
8
starerlloll 2022-04-21 11:53:05 +08:00 1
我觉得主要问题是 3-4 个月才合并一次代码。。这频率太低了。。。还有 20 多个开发,,
|
9
GeruzoniAnsasu 2022-04-21 11:56:16 +08:00
PLEASE (大写强调) 最长周期 一周
合一次代码 开发周期和代码同步周期完全是两回事,代码同步频率拉起来你遇到的依赖问题全都不存在了 啊,你说没写完同步代码没意义,所以为什么不把任务拆细一点每个可以跑的单元都尽可能小呢,这不就「敏捷」起来了 |
10
securityCoding 2022-04-21 12:04:42 +08:00 via Android
@sadfQED2 大仓模式下都在主库搞分支不现实的。
|
11
laozhoubuluo 2022-04-21 12:14:45 +08:00 2
1. 一个开发团队开发一个新功能开发周期 3 - 4 个月说明软件架构有严重问题,绝大多数项目和公司根本接受不了这个周期。建议需求规划端做合理拆分,单个需求用 4 个月不如拆成 20 个需求每个一周会更合理。如果没法拆分那也没办法,说明软件架构积重难返了,如果您不是给金融行业写 COBOL 的工作建议尽快转行。
2. 如果确实积重难返的话也有办法缓解,如果一个需求 7 天之内做不完,那么每周需要找一天 rebase 每个需求的 dev 仓库,保证当时 dev 仓库的内容是主线 Dev 仓库 + 新增内容,可以保证合并期间不那么折腾,相当于牺牲开发进度保证最后合并成功率。 |
12
wd 2022-04-21 12:17:48 +08:00 via iPhone 1
你需要的恐怕是多花点钱雇几个靠谱的人...
|
13
zpxshl 2022-04-21 13:04:19 +08:00 via Android
我们主仓几万条分支,还有大量子仓,同样分支爆炸
|
14
FranzKafka95 2022-04-21 13:09:26 +08:00 via Android
功能开发三四个月不代表你三四个月提交一次吧,更新一点就提交到远程主仓,其他同事及时更新后 merge 到本地个人分支,大家都这样操作就行了
|
15
Building 2022-04-21 13:13:03 +08:00
这就是为什么项目同一个功能的函数能出现好几个的原因,为了方便都手写了一个 private 的给自己专用
|
16
cutepig 2022-04-21 13:34:11 +08:00 via Android
我们这边有类似的问题,我们总结原因在于软件设计不好。模块化做的不好。code review 不够。代码修改太随意。
我们正在通过 pull request 做 code review ,希望能够改善情况 仅供参考 |
17
jasondennis12139 OP @starerlloll 肯定不是 3 个月才合一次,是一个很大的新增需求,覆盖了几乎所有模块,并且直接催生了一个新的微服务。期间不停的在向开发分支提交代码,也定期 merge 到测试分支。但是在大范围提发布到发布分支的时候出了问题。
|
18
mozhizhu 2022-04-21 14:28:49 +08:00
AB 相互依赖部分抽离出来,做 Base ,每次变化都基于 Base 修改(开发阶段支持 A 、B 单独调用),Base 及时进行测试和内部发布;尽量不要因为 AB 同改,最后合并爆炸
|
19
Huozy 2022-04-21 19:37:38 +08:00 1
不建议 fork 到个人仓。
假定 Master 分支为生产版本代码,测试环境分支 test ,验证环境分支 UAT 。生产发布周期为 7 天一次。 Master 、UAT 、test 分支均受保护,普通开发无法直接提交或合并。 需求 A 从 Master 分支切出一个 dev_A ,需求 B 从 Master 切出 dev_B ,dev*分支都是由开发个人维护的,做相应需求开发。 dev*分支在开发过程中应在每个上线周期后与 mater 进行同步。 开发完成后,发起合并请求至 test ,上测试。由专人进行合并管理解决冲突。 假定上线日为 T 日,那么在 T-7 日时,应将已经测试完成的 dev_A ,由专人合并至 UAT 分支,发布进行验证测试。完成后将 UAT T-7 日版本 打包进入待上线,T 日发布。 发布成功后,T+1 日将 UAT 分支合并至 Master 分支,并打上 tag 。 假设 T+2 日,发现重大 BUG ,应从 Master 分支切出 BugFix 分支修复,并直接合并至 UAT 分支进行测试验证再发布。 理论上来说,test 分支上的 feature 功能不会与 UAT 同步,即某些功能上了测试,但可能最终都不会正式发布,那么此时 test 分支已经与 Master/UAT 相差较远,所以 test 分支应该定期删除,重新从 Master 分支切出,再将 dev*合入 test 分支进行测试。 上了 UAT 分支的代码,一定是要发布至生产的,如不发布,需要回退 UAT 分支。 如果你的 A 需求与其他需求代码出现大量冲突或者大量依赖的,需要团队负责人对开发周期进行考量和调整。 git 工作流没有办法完全解决代码冲突,只是尽可能的减少冲突出现。 |
20
dlsflh 2022-04-21 21:48:52 +08:00
大家好,请问楼上这些知识看什么书能获得?
|
21
duke807 2022-04-22 01:59:42 +08:00 via Android
建議用 gerrit ,不需要 fork 到個人倉,主庫也不會分支爆炸,多人研發同步進度也及時
|