各位大佬你们团队开发 git 是如何管理的？

[liuchengfeng1]

最好是 10 个人以上的技术团队，你们面对 版本协作开发、版本上线顺序前后不一致、开发途中穿插需求或是解决 bug 、如何减少代码冲突等等，是怎么处理的呢？有什么比较好的 git 管理方法

目前我们是这样：

从 prod 单独拉一个 release 分支，然后 4 、5 个人在这个分支上开发，按功能区分模块，完成后让某个人合到 dev 、test

但是有个问题，开发的人一多，这样特别容易造成代码冲突

[amon]

随着人数增加和项目复杂度的提升，解决代码冲突已经不是 Git 范筹的问题，要从项目和人员的组织架构上调整，以及工作流程的重新定义。
- 代码结构要更松散，减少耦合。比如拆分文件和项目，如微服务
- 工作内容的重新划分，比如由以前的一坨进行水平或垂直拆分；由以前的水平拆分，变成垂直拆分；或由以前的垂直拆分变成水平拆分

[horizon]

gitlab flow

[yagamil]

尽量少动别人的代码，动了之后就要马上提交，写好注释。

[vx7298]

开发：
1 ， 每个人只能从 dev 合并到自己
2. 功能开发 ok 后，才合并到 dev ，并且有专人审核，必须 build ok

bug：
1 ， 牵头人，拉分支
2 ， 所有相关人员的改进，必须有由牵头人负责审核合并，

[gorvey]

冲突是必然的，你们尝试过用插件统一格式吗，比如前端项目的 eslint/prettier 。

如果每个人的编辑器配置不同，哪怕只修改一部分代码，整个文件的格式都会乱，这样冲突会更多

[vx7298]

@gorvey ，，对，，冲突是必然的，多人开发，没有不冲突的，不要从内心里排斥冲突，而是从架构角度管控和解决冲突，git 相当强悍和完美，一旦冲突凌乱无从下手，八成是架构上没理解到位，多人之间目前和方案严重对立，这时候，就是开会了，哈哈，，统一思想

[fields]

每个人新增功能/处理 bug 就建一个个人分支呀，每个个人分支只做一个相关功能的 bug 修复或只增加一个新特性，然后 review 合并到 dev 分支上，之后删除自己的个人分支，循环往复。

如果有 ci/cd 的话，就每天出个包给到测试那边，测试那边去回归测试

最后从 dev 建个 release 分支，给测试用来做稳定性测试、系统测试等等

[tom]

1 个固定分支：

- **master**：主分支。所有的 feature 和 bugfix 分支都从该分支创建。该分支受保护，不允许直接向该分支提交代码

3 个短期分支，完成功能开发之后需要删除：

- **feature/\***：功能分支。用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 master 分支，之后删除该分支
- **bugfix/\***：bug 修复分支。用于修复不紧急的 bug ，普通 bug 均需要创建 bugfix 分支开发，开发完成自测没问题后合并到 master 分支，之后删除该分支
- **release/\***：发布分支。用于代码上线准备，该分支从 master 分支创建，创建之后发布到测试环境进行测试，测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复，所有 bug 修复完后，在上线之前，需要合并该 release 分支到 master 分支。release 分支可以长期保留

[me1onsoda]

代码冲突处理在现代 IDE 已经不算个事了吧，图形化操作

[mioktiar56]

直接往 master 干，反正就一个人

[zackzergzeng]

我们比较简单粗暴，就在 master 上开发提交，然后 release 的时候再从 master 拉出 release 分支，修 bug 的时候把提交 cherry-pick 到各个需要修复的 release 版本

[gitrebase]

公共的就一个 master 分支，有新功能或者 bugfix 就自己基于 master checkout 一个新分支，写完后、测试后 merge 到 master ，打个 tag ，根据 tag 走发布

[Ravenddd]

使用 github flow ，其实就是社区玩法，再融合一些企业特点的改变。
master 、release 、test 、dev：分别是部署环境的分支，需要部署才合并上来
n 个 feature 分支：需求开发的分支，理想状态下，需要每个 feature 测试完成再合并到 release 和 master ，但是实际的企业环境可能是多需求单测试环境，所以可以以下操作：
- 开发：测试自己的代码，但是由于依赖其他服务，feature 合并到 dev 分支，部署自测/联调
- 测试：feature 合并到 test 环境，给测试人员过测试用例
- 预发部测试：feature 合并到 release ，部署测试
- 正式发布：feature 合并到 master ，部署

PS：注意每次修复 bug ，到需要在 feature 分支修复，再合并到部署分支，因为需求可能随时回滚，部署分支可能会回退。这个工作流基本满足大部分开发团队和需求情况。

[coderzhangsan]

我也想走标准的 git-flow 流，奈何我司是小公司，迭代非常快，要支持这种场景，我司的 git 管理是这样的：只保留 master 这一个维护分支，不设置 dev 分支，多个 feature 分支

[declandragon]

前端 12 个开发分支，后端 3 个开发分支，一个需求占一个，上线之前把 master 合并到当前的开发分支就行

[coderzhangsan]

不小心按了 enter ，重发：
我也想走标准的 git-flow 流，奈何我司是小公司，迭代非常快，要支持这种场景，我司的 git 管理是这样的：只保留 master 这一个维护分支，不设置 dev 分支，一个 test 分支(支持多个 feature 分支并行测试，冲突是难免的)，test 分支需要周期性删除，重新从 master 分支 checkout ，保证 test 分支不至于过于混乱，测试完毕后，feature 直接合 master 分支。

[jaylee4869]

每一个 需求/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 ，十多年的老项目，几万个历史分支，十几个人的团队，遇到冲突的情况很少。

[arischow]

GitLab Flow + Atomic MR ，小步快跑

[qeqv]

@coderzhangsan 你这个 test 分支感觉和 dev 差不多

[br_wang]

冲突多，看看是不是代码结构不太合理，为什么很多人要同时改动同一个文件？