Git 分支管理：从入门到规范，这是我见过最好的实践总结

最近项目已经发布到了生产环境，处在试运行阶段。有时候要开发新需求，有时候要修复bug。所以分支管理迫在眉睫。

接下来，我将分享一下团队内部推行的 Git 分支管理策略。不过度复杂，但很有必要的四大核心分支：master、develop、feature、hotfix，给大家分享一下。欢迎大家评论区讨论留言~

一、四大核心分支介绍

🚀核心操作流程详解

1. 开发新功能 (Feature)

流程：从 develop 拉取功能分支 -> 开发 -> 自测通过 -> 通过PR合并回 develop -> 集成测试通过

2. 发布新版本 (Release)

流程：从 develop 发布到 master -> 打 Tag -> 部署

3. 修复生产环境紧急Bug (Hotfix)

流程：从 master 拉取热修复分支 -> 修复 -> 自测 -> 合并回 master (打Tag发版) 和 develop

💡关键最佳实践与提醒

1. 保护分支将 master 和 develop 分支设置为保护分支，禁止直接推送，必须通过 Pull Request 并完成代码审查后才能合并。
2. 提交信息规范遵循约定式提交（如 feat: , fix: , docs: ），便于追溯和生成变更日志。
3. Tag 而非分支发版发布应基于 master 分支上的Tag，而非某个分支。Tag 标记了一个不可更改的历史点，更适合版本化。
4. 立即同步hotfix 在合并到 master 后，必须立即合并回 develop，防止后续开发覆盖修复。

总结：遵循这套以 master 、 develop 、 feature 、 hotfix 为核心，并强调基于 Tag 发版的规范，能让团队协作清晰高效，版本发布和紧急修复流程可控。

二、新功能与修复bug的详细流程

1、开发新功能

从develop分支（至少和master分支一致，甚至比master分支的代码新）上拉取新分支feature/0911进行新功能开发。开发完成并自测通过后，合并到develop分支（其他人的新功能开发好后也要合并到该分支），在测试环境做集成测试。

develop分支发版前，要先把master分支（包含了所有 hotfix）的代码合并到develop分支上，防止有hotfix忘合并到develop，导致代码缺失。

在develop分支上进行集成测试。测试通过后，再将develop分支合并到master分支，master分支打tag，基于tag进行发版到生产环境。

2、修复bug

如果生产环境出现了 bug，就从 master 分支上拉取 hotfix/0911 分支进行 bug 修复。bug 修复好，在本分支进行测试。测试通过后，将分支代码合并到 master 分支以及 develop 分支。

3、发版到生产环境

在 master 分支打 Tag，基于 Tag 发布新版本到生产环境。Tag 可以确保您任何时候都能重新部署出与生产环境完全一致的版本。