最好是 10 个人以上的技术团队,你们面对 版本协作开发、版本上线顺序前后不一致、开发途中穿插需求或是解决 bug 、如何减少代码冲突等等,是怎么处理的呢?有什么比较好的 git 管理方法
目前我们是这样:
从 prod 单独拉一个 release 分支,然后 4 、5 个人在这个分支上开发,按功能区分模块,完成后让某个人合到 dev 、test
但是有个问题,开发的人一多,这样特别容易造成代码冲突
1
weixind 128 天前 4
|
2
miaotaizi 128 天前
差不多都是这样吧
|
3
Xu3Xan89YsA7oP64 128 天前
gitflow ,代码分支自上而下的同步得写脚本之类的自动进行
冲突在所难免,超过 500 行代码就该提交下进行冲突处理和 code review 了 |
4
liuchengfeng1 OP @miaotaizi 就是想知道还有没有最优解
|
5
iMusic 128 天前
我是这样的,比如大家代码都合并到 develop 分支。
开发新需求我在本地创建一个新分支比如 feat 开发完后切换到 develop 分支拉取最新代码,然后切换回 feat 分支,合并 develop 代码,有冲突解决冲突 再次切换到 develop 分支,合并 feat 代码,最后推上去 develop> git co -b feat 啪啪啪写代码 feat> git co develop develop> git pull develop> git co feat feat> git rebase develop 啪啪啪解决冲突,add, rebase --continue feat> git co develop develop> git merge feat deveop> git push |
6
aababc 128 天前
服务端开发,我们就比较简单了,开发的起点是 master ,从 master 创建 feature 分支,不同的项目需求创建不同的分支,然后合并到 test 进行测试,上线的时候后把 feature 直接合并到 master 。不过这么做也有一个小问题,大家在功能测试的时候比较容易互相影响,但是总体还是可控的。
|
7
catinsides 128 天前 3
如果避免不了很多人修改同一个文件同一处代码,项目结构也得调整吧,靠 git 可能无法解决
|
8
justplaymore 128 天前 6
“开发的人一多,这样特别容易造成代码冲突”
这个和 git 分支策略没有太大关系,根本问题是在项目本身的结构设计是否合理,功能模块划分是否清晰,每个类的职责是否足够单一。 冲突是在分配开发任务的时候就决定了的,而不是在做分支策略的时候决定的。 如果这些任务对应的代码是不够独立清晰的,那么冲突就是必然的。 |
9
liuchengfeng1 OP @aababc 俺们也是这样
|
10
DamonLin 128 天前
开发前多拉开发分支的代码,不要一次性提交太多代码,多人开发冲突是难以避免的,解决冲突还是要细心。
|
11
liuchengfeng1 OP @weixind 不太适合呀,就是一个项目迭代太多了。I won’t talk about any of the projects’ details, merely about the branching strategy and release management.(我不会谈论任何项目的细节,只会谈论分支策略和发布管理。)
|
12
liuchengfeng1 OP @weixind 就是不太适合呀,就是一个项目里迭代太多了。I won’t talk about any of the projects’ details, merely about the branching strategy and release management.(我不会谈论任何项目的细节,只会谈论分支策略和发布管理。)
|
13
liuchengfeng1 OP @DamonLin 真的是 事在人为😂
|
14
isnullstring 128 天前
一开始老项目换 Git 时候也遇到类似问题,后面重新整理代码,拆分功能
各自管各自的,冲突也减少,即使有紧急 BUG 或者需求要上都不影响 |
15
qxhnks 128 天前 via iPhone
Google 搜 trunk-based development
|
16
yanqing07 128 天前
@liuchengfeng1 #4 都是在这基础上变,适合自己项目就好。代码冲突是无解的,所以才要将功能拆分到不同文件,用现在的话说,就是分模块。
举例,如果两个人同时要在一个页面做开发,这个页面有个入口文件(index.ts|js),他们各自写自己模块( a.ts,b.ts ),在 index.ts 引入这两个文件。基本上冲突就只在 index.ts 出现,只要没人在 index 写大段业务逻辑,可以说基本冲突为零。 |
17
weixind 128 天前
@liuchengfeng1 #11 冲突是必然的,要想办法减小冲突的粒度。开发分支要多 rebase develop 分支,多次解决冲突,不要最后堆到一块解决。同时项目模块划分要更清晰。
|
18
miaotaizi 128 天前
可以试试 dev 分支 更新了之后要求 各个 feature 分支将 dev 合并到自己分支内部会不会好些
|
19
qxhnks 128 天前
|
20
xuld 128 天前 1
按上线计划拆分分支,而不是一个功能一个分支,也不是一个人一个分支。假定上线计划是一周一发布,那 dev 分支放本周需要上线的内容,如果有内容需要本周开发,但不知道什么时候上线,或者你们上线计划经常变化,那建立单独 dev 分支。每个功能做完之前拉代码,做完立即提交。每个人都这样做,问题就不会太大。
|
21
amon 128 天前
随着人数增加和项目复杂度的提升,解决代码冲突已经不是 Git 范筹的问题,要从项目和人员的组织架构上调整,以及工作流程的重新定义。
- 代码结构要更松散,减少耦合。比如拆分文件和项目,如微服务 - 工作内容的重新划分,比如由以前的一坨进行水平或垂直拆分;由以前的水平拆分,变成垂直拆分;或由以前的垂直拆分变成水平拆分 |
22
horizon 128 天前
|
23
yagamil 128 天前
尽量少动别人的代码,动了之后就要马上提交,写好注释。
|
24
vx7298 128 天前
开发:
1 , 每个人只能从 dev 合并到自己 2. 功能开发 ok 后,才合并到 dev ,并且有专人审核,必须 build ok bug: 1 , 牵头人,拉分支 2 , 所有相关人员的改进,必须有由牵头人负责审核合并, |
25
gorvey 128 天前
冲突是必然的,你们尝试过用插件统一格式吗,比如前端项目的 eslint/prettier 。
如果每个人的编辑器配置不同,哪怕只修改一部分代码,整个文件的格式都会乱,这样冲突会更多 |
26
vx7298 128 天前
@gorvey ,,对,,冲突是必然的,多人开发,没有不冲突的,不要从内心里排斥冲突,而是从架构角度管控和解决冲突,git 相当强悍和完美,一旦冲突凌乱无从下手,八成是架构上没理解到位,多人之间目前和方案严重对立,这时候,就是开会了,哈哈,,统一思想
|
27
fields 128 天前
每个人新增功能/处理 bug 就建一个个人分支呀,每个个人分支只做一个相关功能的 bug 修复或只增加一个新特性,然后 review 合并到 dev 分支上,之后删除自己的个人分支,循环往复。
如果有 ci/cd 的话,就每天出个包给到测试那边,测试那边去回归测试 最后从 dev 建个 release 分支,给测试用来做稳定性测试、系统测试等等 |
28
tom 128 天前 2
1 个固定分支: - **master**:主分支。所有的 feature 和 bugfix 分支都从该分支创建。该分支受保护,不允许直接向该分支提交代码 3 个短期分支,完成功能开发之后需要删除: - **feature/\***:功能分支。用于开发新的功能,不同的功能创建不同的功能分支,功能分支开发完成并自测通过之后,需要合并到 master 分支,之后删除该分支 - **bugfix/\***:bug 修复分支。用于修复不紧急的 bug ,普通 bug 均需要创建 bugfix 分支开发,开发完成自测没问题后合并到 master 分支,之后删除该分支 - **release/\***:发布分支。用于代码上线准备,该分支从 master 分支创建,创建之后发布到测试环境进行测试,测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复,所有 bug 修复完后,在上线之前,需要合并该 release 分支到 master 分支。release 分支可以长期保留 |
29
me1onsoda 128 天前
代码冲突处理在现代 IDE 已经不算个事了吧,图形化操作
|
30
mioktiar56 128 天前
直接往 master 干,反正就一个人
|
31
zackzergzeng 128 天前
我们比较简单粗暴,就在 master 上开发提交,然后 release 的时候再从 master 拉出 release 分支,修 bug 的时候把提交 cherry-pick 到各个需要修复的 release 版本
|
32
gitrebase 128 天前
公共的就一个 master 分支,有新功能或者 bugfix 就自己基于 master checkout 一个新分支,写完后、测试后 merge 到 master ,打个 tag ,根据 tag 走发布
|
33
Ravenddd 128 天前
使用 github flow ,其实就是社区玩法,再融合一些企业特点的改变。
master 、release 、test 、dev:分别是部署环境的分支,需要部署才合并上来 n 个 feature 分支:需求开发的分支,理想状态下,需要每个 feature 测试完成再合并到 release 和 master ,但是实际的企业环境可能是多需求单测试环境,所以可以以下操作: - 开发:测试自己的代码,但是由于依赖其他服务,feature 合并到 dev 分支,部署自测/联调 - 测试:feature 合并到 test 环境,给测试人员过测试用例 - 预发部测试:feature 合并到 release ,部署测试 - 正式发布:feature 合并到 master ,部署 PS:注意每次修复 bug ,到需要在 feature 分支修复,再合并到部署分支,因为需求可能随时回滚,部署分支可能会回退。这个工作流基本满足大部分开发团队和需求情况。 |
34
coderzhangsan 128 天前
我也想走标准的 git-flow 流,奈何我司是小公司,迭代非常快,要支持这种场景,我司的 git 管理是这样的:只保留 master 这一个维护分支,不设置 dev 分支,多个 feature 分支
|
35
declandragon 128 天前
前端 12 个开发分支,后端 3 个开发分支,一个需求占一个,上线之前把 master 合并到当前的开发分支就行
|
36
coderzhangsan 128 天前
不小心按了 enter ,重发:
我也想走标准的 git-flow 流,奈何我司是小公司,迭代非常快,要支持这种场景,我司的 git 管理是这样的:只保留 master 这一个维护分支,不设置 dev 分支,一个 test 分支(支持多个 feature 分支并行测试,冲突是难免的),test 分支需要周期性删除,重新从 master 分支 checkout ,保证 test 分支不至于过于混乱,测试完毕后,feature 直接合 master 分支。 |
37
jaylee4869 128 天前
每一个 需求/bug 一个分支,遵循 [type]/[title] 的分支名:
feat/add-user feat/enable-rbac feat/support-kubernetes-deployment fix/issue-233 fix/npe-error feat/JIRA-SERVICE-197 hotfix/JIRA-20240808 测试的时候都往某个专门的分支上 merge 或者走 pull request developer A: branch feat/add-user merge into test developer B: branch fix/issue-233 merge into test 此时 developer A 早已经准备上线了: developer A: branch feat/add-user merge into prod (这时候其实可以 git tag ) 上线没问题,feat/add-user 就可以直接删了,或者放着不动,后续如果这个需求有 bug 了,一定不要继续用这个分支,直接从上次发布的分支上 checkout ,继续往返前面的操作就可以了。 永远不要使用自己的个人分支,不要把分支想象的一个很长远的东西;除了主要用于 发布 的分支,其他一切分支都视作临时的分支。你越是用自己个人固定的分支,冲突就越多,因为你总是要把 prod 分支往自己分支上 pull ,何必呢,看着都累。 之前在某美企,分支全都是用的 JIRA ID ,十多年的老项目,几万个历史分支,十几个人的团队,遇到冲突的情况很少。 |
38
arischow 128 天前
GitLab Flow + Atomic MR ,小步快跑
|
39
qeqv 128 天前
@coderzhangsan 你这个 test 分支感觉和 dev 差不多
|
40
br_wang 128 天前
冲突多,看看是不是代码结构不太合理,为什么很多人要同时改动同一个文件?
|
41
jiangzm 128 天前
@horizon 这个图一看就有问题, 至少要有一个对应线上版本的分支不能每个分支都是一直变动的,可以是 master 也可以是其他。
假如 master 是对应线上版本的,那 master 只能接受来自发布分支(release&hotfix)的合并,原则就是没上线的功能不能合到 master 。hotfix 和 release 可能是并行存在的,那 hoftix 发完同时要合并到 master 和 release ,那这样中间再开 hotfix 以及发布和新开 release 分支均不会漏 hotfix 内容。 |
42
NessajCN 128 天前
学 Linus 呗
每个部门自己拉一个 branch 部门内部再从部门的 branch 拉各自的 feature 完成了就 commit 自己的 feature, 部门负责人就负责 review 然后把 feature merge 到部门 branch CTO 就负责从部门 branch merge 到 master 如果另外还需要 test 或 release 就都从 master 分 |
43
feiyan35488 128 天前
|
45
allecnm 128 天前
开发从 master 拉 ft , 然后测试环境 test ,最后上线用 release
|
46
Exxfire 128 天前
我们领导喜欢不同分支间用 beyond compare 合并代码。
|
47
jiangzm 128 天前
@horizon #44 图里面 release 是作为发布分支,master 看着像开发/测试分支。
发布分支在发布阶段还可能是变动的怎么可能对应的是线上呢? master 保持最新是开发功能的最新吗?那就是常规 dev/test 分支功能了,这个没问题很多团队在 master 上开发。 名字其实无所谓,只要有特定的分支做测试/特定的分支做发布/特定的分支对应线上版本 就够了。 这个图里面 feature 从 master 开出来,然后又合并到 master ,理论上就是作为 dev/test 分支功能作为集成测试分支。如果是作为开发/测试分支用,那 feature 分支就不能从 master 开出来了, 一定是一个对应线上版本的分支。 |
48
xsen 128 天前
1. 拆。项目、服务、模块进行拆分,不同代码库
但个代码库避免过多人维护,一般一个代码库 2-3 人维护;若不满足,则拆分代码库 2. master/dev 分支,dev 为开发分支,每个人开发都是直接在 dev 开发 a ) 1 天至少从 dev pull 一次代码(合并,基本不会冲突),子功能开发完(单元测试通过或编译通过),提交 dev b )测试后,dev 合并至 master |
50
horizon 128 天前
|
51
0xD800 128 天前
个人经验:冲突可以从代码设计上解决,而不是 git 工作流上优化,有一些冲突是无法避免,如果经常遇到同一个文件的冲突,我建议从代码结构上进行拆分优化。
|
52
sungx1202 128 天前
永远从 master 新切分支,dev 是一个测试汇总池子,所有改 bug/迭代的分支 等汇聚 dev ,发布 pro 时按需 mr (合并请求) mster ,编译打包发布,永远不从 dev 合并 master 。
|
54
liuchao719 128 天前
@0xD800 说的太对,耦合太重了,或者文件太大导致一个人搞不定。
|
55
qxdo1234 128 天前
没有比较好的方案,实际上 git 只是个工具,还是要靠人治,制定 git 工作流,其他的分支 要多从源分支反合并,才能减少冲突,而且也无法确保一定就不出错,git 工具是不会出问题的,只要有人参与做的事情,出问题都是人的问题,
|
56
ChangJingli 128 天前
|
57
hqpsoft 128 天前
每天自动把主干分支反向 merge 到各个 feature 分支, 有冲突尽早解决.
|
58
mark2025 128 天前
如果是多版本发布策略,用 1 楼图片那种,如果是单版本滚动发布就用 gitlab flow
|
59
yb2313 128 天前
每个小时合并一次主开发分支, 这样就很轻松了
|
60
maninfog 128 天前 via iPhone
TBD + Feature Toggle
|
61
fkname 128 天前
一个 master 分支,一个 dev 分支,开发都在 dev ,自己 fork 一个仓库提 mr 合 dev ,有 committer 和特性责任人检视,自验完打 tag 出包转测试,每个人提交代码要保证自验和正常启动,每次提交不能超过 500 行。发布时从 dev 合 master 。
线上补丁从 master 拉分支出来修改后双合 master 和 dev 。 |
62
csys 128 天前
|
63
csys 128 天前 1
多说一句,gitflow 已经成为了现代软件的一种灾难
|
64
wupher 127 天前
简单的项目 gitflow
更快速或者高效的团队可以考虑 github-flow 或者 gitlab-flow 。 有奇葩要求的,也可以自己团队商量一套实践。 但是、但是,总会有 2B 的领导或者不写代码的“技术牛人”,跳出来要求“统一”“规范”,最后搞出个缝合怪。 |
65
southsala 127 天前
你这个等所有人在一个分支上开发
你可以在 release 上多分出几个分支,一个 feat 或者一个组分配一个 release 的子分支,结合 gitflow 看看 |
66
p1gd0g 127 天前
还是能力问题,git 本身够简单了。有的同事死活搞不懂,已合并就覆盖别人。习惯太差
|
67
shijingshijing 127 天前 1
对于中小公司,真心一劝,像 svn 那样中心化来用 git 是最好的,在满足自身业务版本控制需求前提下,流程越简单越好,血泪教训。
|
68
godwinma 127 天前
我觉得多人一起开发的时候冲突不可避免,谁后提交,谁解冲突。哈哈。
|
71
lasuar 127 天前
有“经常冲突” 这个问题说明 代码组织结构 有优化空间。
|
73
stonesirsir 127 天前 via Android
建议用 rebase ,不要用 merge ,后期会明了很多
|