最近项目已经发布到了生产环境，处在试运行阶段。有时候要开发新需求，有时候要修复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 可以确保您任何时候都能重新部署出与生产环境完全一致的版本。

推荐一门程序员画图课程

最近有小伙伴们问我有没有教程序员画流程图的课程，想画的既好看又清晰易懂。正好我这之前也有系统学过这块知识，专栏名叫「程序员的全能画图课」：

该专栏已经完结，共25篇文章，83.6K字数。可以先看下目录，内容确实很好，非常值得学习画流程图的朋友入手。

之前我还写过一篇介绍，感兴趣的可以看一看：

Ending

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标～谢谢你看我的文章，我们下次再见。

我的 vx 是【create17_】，有需要的可以找我。

最后，把我的座右铭送给大家： 执行是消除焦虑的有效办法，明确并拆解自己的目标，一直行动，剩下的交给时间。共勉