Git分支管理实践

引言

多人协作开发如果所有人直接往master主分支提交，代码很容易混乱、出现问题无法回滚。一套清晰的分支命名和合并规则，是团队开发协作的基础。

常见分支模型

• master/main：稳定生产分支，只接受合并，不直接开发；
• develop：日常集成开发分支；
• feature/xxx：单个功能开发分支，从develop拉出；
• hotfix/xxx：线上紧急bug修复分支，从master拉出；
• release/x.x：版本发布前测试分支。

常用命令

# 新建并切换功能分支
git checkout -b feature/login

# 提交代码
git add .
git commit -m "新增登录接口"

# 推送到远程
git push origin feature/login

开发流程

1. 从develop拉取新功能分支；
2. 本地开发提交，定期同步develop最新代码；
3. 测试通过后发起合并请求(MR/PR)；
4. 代码评审通过合并到develop；
5. 上线前拉出release分支测试，最终合并master打tag。

注意事项

• 功能分支命名要语义化，带上开发人或需求编号；
• 每次提交信息写清楚改了什么；
• 不要在长期分支堆积大量提交，频繁同步主干避免冲突；
• hotfix修复完成后要同步回develop，防止下次版本再次出现bug。

总结

Git分支模型不追求复杂，适合团队规模即可。核心原则：主干保持稳定，功能独立分支，小步提交，评审合并，线上问题走hotfix单独修复。