5人中小团队Git分支规范（极简落地版，不复杂、好执行）

5人中小团队Git分支规范（极简落地版，不复杂、好执行）

5人属于典型小型开发团队，不建议每人长期持有独立永久分支，会造成分支泛滥、合并冲突难管理；采用「主干稳定分支 + 功能短期分支」模式，兼顾简单、安全、协作高效。

一、固定长期主干分支（仅2条，永久存在）

1. `main` / `master` 生产分支（线上环境）

权限：仅管理员/组长可合并，禁止任何人直接push
规则：任何时候代码必须能直接打包上线，不能存在未完成功能、bug
来源：只能由 release/*、hotfix/* 合并进来

2. `dev` 开发集成分支（测试环境）

团队日常开发汇总分支，所有功能开发完成后先合并到这里，统一测试

权限：所有人可提交MR/PR，组长审核合并
状态：允许存在待测试新功能，但不能大面积崩溃
作用：测试、联调、预发布验证

5人团队不需要多环境分支（test、pre等），dev 一套测试环境足够，减少维护成本。

二、临时短期分支（所有人共用规范命名，用完即删）

核心原则：一个需求/一个bug对应一条分支，开发完合并、删除分支，不长期留存

1. 功能分支 feature（日常新需求、迭代开发）

适用：新页面、接口、业务功能、需求迭代命名规范：feature/姓名缩写-需求单号-简单描述 示例： feature/zhangsan-0218-user-login feature/lisi-order-pay

生命周期：

从 dev 拉取创建
本地开发、频繁commit，定期同步dev代码解决冲突
开发自测完成 → 提MR合并到dev
合并通过、测试无问题 → 直接删除该feature分支

2. 紧急修复分支 hotfix（线上bug）

适用：线上main环境出现阻断性bug，紧急修复命名：hotfix/姓名-问题简述 示例：hotfix/wangwu-pay-calc-error

流程：

直接从 main 拉分支（不要从dev）
修复完成后：
- 先合并到 main 上线修复
- 再同步合并到 dev，保证两边代码一致
上线完毕删除hotfix分支

3. 版本发布分支 release（迭代封版准备上线）

适用：一整个迭代全部功能开发完毕，统一上线前的回归、小修小补命名：release/v1.2.0 流程：

从 dev 拉出release分支
只改bug、优化文案，禁止新增大功能
测试全部通过后合并到 main 打版本tag
同步合并回dev，删除release分支

三、回答你的核心疑问：每个人需要专属个人分支吗？

不推荐单独创建永久个人分支（如 `zhangsan-dev`）

弊端（5人团队尤其明显）：

分支数量爆炸，没人维护，长期滞后dev，合并时大量冲突；
多人协作同一需求时，代码分散在不同个人分支，联调困难；
容易出现“自己分支藏代码不合并”，集成阶段集中爆雷。

替代方案（更适合5人小团队）

不用永久个人分支，改用「按需求建临时feature分支」 谁负责这个需求，feature分支就带上谁的名字，天然区分归属；一人同时做多需求，就创建多条feature分支，互不干扰。
本地可以随便切分支，但远程仓库只保留上面3类临时分支，开发完清理。
如果有人需要本地存草稿、未完成半成品：仅本地分支，不要推送到远程。

四、5人团队配套协作强制规范（简单易落地）

1. 拉取、推送规则

所有新分支统一基于最新 dev 创建：

git checkout dev
git pull
git checkout -b feature/xxx

开发期间每天至少同步一次dev，提前解决冲突，避免最后合并大量代码冲突：
```
git checkout feature/xxx
git pull origin dev
```
禁止直接 git push 推送到 dev / main，必须走MR/PR审核。

2. Commit提交规范（统一日志，方便追溯）

格式：类型(模块): 简短描述 类型：feat新功能 / fix修复bug / refactor重构 / docs文档 / test测试示例： feat(user): 新增手机号登录 fix(order): 修复金额计算错误

3. MR/PR审核规则（5人轻量化流程）

提交MR目标分支统一选 dev；
至少1名同事简单看一遍代码即可合并（小团队不用多层审批）；
MR必须自测、简单说明改动内容；
合并优先用 Squash合并：把该功能所有提交压缩成一条干净commit，保持dev提交记录整洁。

4. 线上版本Tag规范

每次合并release到main，必须打版本标签，方便回滚：

git tag -a v1.2.0 -m "版本1.2.0上线"
git push origin v1.2.0

五、完整工作流程举例（新人一看就懂）

场景：张三做用户登录新需求

切到dev，拉最新代码：git pull origin dev
创建功能分支：git checkout -b feature/zs-user-login
本地开发、多次commit，每天同步dev解决冲突
开发自测完成，推送远程分支：git push origin feature/zs-user-login
在Git平台（Gitee/GitLab/Github）创建MR，目标分支dev，发给同事审核
审核通过，Squash合并到dev，删除远程feature分支
测试环境拉dev代码测试，有小bug就在同分支修改，重新推送更新MR

场景：线上支付bug紧急修复

从main拉hotfix分支：git checkout main && git pull && git checkout -b hotfix/zs-pay-bug
修复、自测，MR合并main上线
再把hotfix代码合并到dev，两边代码同步，删除hotfix

六、极简总结（适合5人小团队，无冗余）

长期分支：main（线上）、dev（开发测试）两条；
临时分支：feature（需求）、hotfix（线上bug）、release（版本封版），用完即删；
不设立长期个人专属远程分支，需求分支自带开发人标识区分归属；
所有合并走MR审核，禁止直推主干；
每天同步dev，提前消化代码冲突，降低集成成本。

Squash 合并就是把多个提交压缩成一个，让主分支的历史记录更干净。‌‌‌ 官网‌

‌具体咋做‌：把功能分支上的一串修改记录打包，变成一个新的提交记录合入主分支。 ‌有啥好处‌：避免主分支里全是“修复 typo”这种细碎记录，只看得到功能完成的大节点。 ‌要注意啥‌：合并后主分支不保留原分支的详细历史，但原分支本身不受影响

Git 分支规范