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