简介：面向开发团队的Git分支流程开发规范文档，提供了一套标准化的分支管理方案，其核心价值是解决多人在同一仓库协作时的分支混乱与合并冲突问题。资源共包含一个Word文档，压缩包仅239KB，内容精炼，便于随时查阅。规范详细定义了主分支、开发分支、功能分支、缺陷修复分支、发布分支、热修复分支六类分支的职责与创建合并规则，并给出了具体命名示例，如feature/material-add、bugfix/MATERIAL-1，方便统一团队分支命名习惯；同时描述了发布分支预发布流程、热修复分支紧急修复流程，以及常用Git操作命令和git flow辅助工具的使用方式。对正在建立研发流程的初创团队或刚接触Git协作模式的新人，这份规范可作内部标准直接参考，帮助团队在开发、测试、发布环节保持清晰有序的分支协作节奏与责任边界。目前已有2178人学习下载，是实践中总结出的分支管理参考资料。
1. 分支管理规范：一份把 Git 流程从「人治」变成「法治」的落地文档
刚把团队从三四个人扩到十几个人的时候，代码库是最容易翻车的阶段。最常见的场景是：新同事直接从 master 拉分支开发，改完合并回 master，结果测试环境刚验证过的代码被另一个人的半成品覆盖了；或者线上出了紧急 bug，大家同时在 master 上改，改完都不知道该回滚到哪一次提交。这份《分支管理规范-GIT分支流程开发规范》解决的就是这类问题——它把 master、develop、feature、bugfix、release、hotfix 六类分支的职责、命名规则和合并方向全部定死，再配合 git flow 插件把流程固化成命令。适合刚扩团队的新人快速上手，也适合内部流程混乱的团队作为整改基准，是一份能直接照着执行的实操文档。
2. 分支模型：master 与 develop 双长期分支，为什么 merge 和 pull 的对象不能乱
2.1 两个长期分支的分工界限：master 只跟线上一致，develop 只收稳定版本
这份规范里最核心的判断是：master 分支的代码必须与线上完全一致，develop 分支记录相对稳定的版本。这两个分支的区别不是「环境」，而是「职责」——master 只接受已经过测试、准备上线的代码；develop 接收所有已完成自测的功能和普通 bug 修复。一旦混用，整个流程就会失真。
我见过不少团队把 develop 当成垃圾桶，功能写了一半也推上去，结果 develop 和 master 的差异越来越大，最后 merge 一次冲突几百个文件。规范里把 develop 定义为「所有 feature 分支和 bugfix 分支的起点」，意味着任何进入 develop 的代码都必须经过功能自测，这个门槛不能省。
以下表格是两类长期分支的使用约束：
| 分支 | 创建来源 | 合并来源 | 合并去向 | 生命周期 |
|---|---|---|---|---|
| master | 初始化时创建 | release 分支、hotfix 分支 | 仅打 tag 后上线 | 永久 |
| develop | 初始化时创建 | feature、bugfix、release 分支 | 只能合并到 release 分支 | 永久 |
实际执行时，master 分支应该设置为受保护分支，只有具备权限的负责人能推送。develop 分支至少要有 code review 环节。
2.2 短期分支的生命周期：feature 和 bugfix 都必须从 develop 拉取
规范反复强调一件事：所有新功能开发和普通 bug 修复，都要从 develop 分支拉取新分支，完成并自测后合并回 develop，然后立刻删除分支。这里容易被忽略的是「从 develop 拉取」这件事本身——很多习惯直接从 master 拉分支的同事，在这个流程里就会遇到合并冲突变多的情况。
feature 分支的生命周期可以用一句话概括：从 develop 长出，合并回 develop，然后消失。bugfix 分支也一样，它针对的是不紧急的 bug，规范里建议用 Jira 单号或者 bug 描述的英文简称命名，比如 bugfix/MATERIAL-1，这样后续查看历史记录时能快速定位对应的问题单。相比之下，hotfix 分支只处理线上紧急问题，必须从 master 创建，合并回 master 的同时还要再合并回 develop，它走的是另一套流程，我们在下一章展开。
短期分支的通用操作序列是：
# 从最新的 develop 拉取功能分支 git checkout develop git pull origin develop git checkout -b feature/material-add # 开发完成后，先提交本地变更 git add --all git commit -m "feat: 新增商品到物料库" # 合并回 develop 前，先把 develop 的最新代码拉下来 git checkout develop git pull origin develop git merge feature/material-add git push origin develop # 删除本地和远程的短期分支 git branch -d feature/material-add git push origin --delete feature/material-add这里有个习惯我很推荐：在合并回 develop 之前，先切到 develop 并执行 git pull，把远端最新代码拉到本地再 merge。否则你基于一个旧的 develop 状态开发，合并时等于和这段时间里别人的所有提交同时冲突，排查起来非常痛苦。
2.3 分支命名规范：把「分支名」当成半个需求文档来写
规范对命名的要求值得单独提出来：feature 分支用能准确描述功能的英文表述，bugfix 分支和 hotfix 分支用 Jira 单号或 bug 英文简称。这不是为了好看，而是为了后期追溯。线上出了问题时，你通过 git log 看分支名就知道这次改动对应哪个需求单或 bug 单。
我自己执行时还会加一个习惯：分支名里不写日期、不写版本号，只写功能描述或单号。因为日期在 commit 历史里就有，版本号在 tag 里有，分支名只承担「这次在做什么」的职责，写多了反而乱。下面是三个参考命名：
| 分支类型 | 场景 | 推荐命名 |
|---|---|---|
| feature | 新增商品到物料库 | feature/material-add |
| bugfix | Jira 单号 MATERIAL-1 对应的 bug | bugfix/MATERIAL-1 |
| hotfix | 线上支付回调报错紧急修复 | hotfix/payment-callback-500 |
提示：feature 分支命名不要用编号，比如 feature/1、feature/2，这类名字在分支多的时候完全无法检索。
3. release 与 hotfix：两条最容易被合并错方向的短命分支
3.1 release 分支：从 develop 长出，最终同时合并回 master 和 develop
release 分支在规范里的定位是「预发布分支」，它从 develop 创建，创建之后由测试同学发布到测试环境进行验证。测试过程中发现的 bug，统一在 release 分支上修复，而不是回到 feature 分支改完后重新合并——这样会让测试环境的内容和分支内容对不上。
release 分支的生命周期是这样的：
- 测试同学提出需要发布测试环境，开发负责人从最新的 develop 拉取 release 分支
- 测试同学把 release 分支部署到测试环境
- 测试发现 bug，开发人员在 release 分支上直接修复并提交
- 所有 bug 修复完成，把 release 分支合并到 master 准备上线
- 同时把 release 分支合并回 develop，保证修复内容同步回开发主线
这里最常见的疑惑是：release 分支上的 bug 修复能不能直接改成在 develop 上修复？答案是能，但不推荐。在 release 分支上修复的好处是，测试环境验证过的代码和你即将上线的代码完全一致，中间不会插入别人的新功能。如果修复在 develop 上，而 develop 已经有人合入了新功能，那测试环境里跑的就不是最终要上线的那份代码。
release 分支的命名规范是用本次发布的主要功能英文简称，比如 release/material-add。如果一次发布包含多个功能，选最核心的那个作为名称即可。
3.2 hotfix 分支：从 master 长出，修复后必须双向合并
hotfix 是规范里唯一允许直接从 master 创建的分支类型，用于紧急修复线上 bug。因为它从 master 创建，所以它天然包含的是线上真实运行的代码，修复完合并回 master 后，线上就能恢复到正确状态。
hotfix 分支的合并方向是规范里最容易出错的地方，它要做两次合并：第一次合并回 master 以便上线，第二次合并回 develop 保证下次发布时包含修复。只合并 master 不合并 develop 的话，会出现线上修复了、但新版本开发分支里还带着这个 bug 的尴尬局面。
# 从 master 拉取 hotfix 分支修复线上 bug git checkout master git pull origin master git checkout -b hotfix/payment-callback-500 # 修复并提交 git add --all git commit -m "fix: 修复支付回调 500 错误" # 合并回 master 并打 tag 上线 git checkout master git merge hotfix/payment-callback-500 git push origin master git tag -a v1.0.1 -m "hotfix: 支付回调 500" git push origin --tags # 同步到 develop，保证下次版本包含该修复 git checkout develop git pull origin develop git merge hotfix/payment-callback-500 git push origin develop # 删除 hotfix 分支 git branch -d hotfix/payment-callback-500 git push origin --delete hotfix/payment-callback-500这段命令里有一个容易被忽略的参数：git tag -a 创建的是附注标签，它会带上打 tag 的人、时间和说明信息。相比之下，git tag 不带 -a 创建的轻量标签只是某个提交的指针，在需要追溯「这个版本是谁发布、包含了什么」时信息量不够。我一般要求团队所有发布都必须使用附注标签。
3.3 为什么 release 合并回 develop 这一步会被漏掉
从我的观察来看，release 分支合并回 develop 这一步是整个流程里最容易被漏掉的环节，原因很实际：上线完成那一刻，所有人的注意力都在「要不要回滚、有没有线上告警」上，很少有人会记得还欠 develop 一次 merge。等想起来时，release 分支已经删了，修复内容散落在 master 的历史里，想找回还得靠 cherry-pick。
解决这个问题，可以在发布流程单里把「合并回 develop」和「打 tag」放在同一个检查项里，或者用下面的 git flow release finish 命令一步完成。但如果你团队不用 git flow，靠人肉记住这两步，就必须在发布检查清单里写出明确条目，不然迟早会漏。
4. 用 git flow 简化分支流程：init、feature、release 与 hotfix 的完整命令
4.1 git flow 初始化与分支配置：一次 init，把命名规范固化
git flow 是 git 的一个插件，作用是把分支流程的命令封装成几个高频动词：start、finish、publish、track。Windows 通过安装包安装的 Git 通常已经自带 git flow，macOS 下可以用 git-flow-avh 项目安装。
初始化时执行 git flow init，git 会引导你确认各分支前缀：
$ git flow init Which branch should be used for bringing forth production releases? - develop - feature-fulltext - feature-vender - master Branch name for production releases: [master] Which branch should be used for integration of the "next release"? - develop - feature-fulltext - feature-vender Branch name for "next release" development: [develop] How to name your supporting branch prefixes? Feature branches? [feature/] Bugfix branches? [bugfix/] Release branches? [release/] Hotfix branches? [hotfix/] Support branches? [support/] Version tag prefix? []大部分选项直接回车使用默认值即可。这里值得注意的参数是 Version tag prefix，如果你的版本号格式是 v1.0.0，可以在这一项填 v，这样 git flow 打 tag 时会自动带上这个前缀。另外，git flow init 只是写入配置到 .git/config，不会污染你的提交历史，所以对已有项目执行也安全。
4.2 feature 分支的三种操作：start、publish、finish
feature 分支对应的 git flow 命令有三组，分别对应创建、推送、合并删除：
# 从 develop 创建 feature/material-add 分支 git flow feature start material-add # 推送到远端，方便和同事协作 git flow feature publish material-add # 合并回 develop 并删除本地和远端分支 git flow feature finish material-addgit flow feature start 会自动基于 develop 创建分支并切换过去，省掉了手动执行 git checkout -b 前面还要保证 develop 最新的步骤。这里也有一个细节：git flow feature finish 执行完会自动切回 develop 并拉取远端更新，然后做合并、再删除分支，一次完成三个动作。刚开始用的时候，我建议先在一个不重要的功能分支上试一遍，确认无误后再在日常开发中放心用。
git flow feature track 是和 publish 配套的命令，当你的同事发布了一个远程 feature 分支，你想在这个分支上继续开发时，用 git flow feature track 分支名 来创建本地跟踪分支。
4.3 release 与 hotfix 的 git flow 命令：一次 finish 完成两次合并
release 和 hotfix 的 git flow 操作核心是 finish 命令，它会自动完成其他分支模型要求的所有合并动作：
# 基于 develop 创建 release 分支 git flow release start material-add # 测试完成后，合并回 master、合并回 develop、打 tag git flow release finish material-add # 发布远端分支和 tag git push --all git push --tagshotfix 的命令语法与 release 相同，区别在于 git flow hotfix start 默认基于 master 而不是 develop：
git flow hotfix start payment-callback-500 # 修复完成后自动合并回 master 和 develop git flow hotfix finish payment-callback-500 git push --all git push --tags提示：git flow release finish 执行时会自动提示输入 tag 信息，默认的 tag 名字是 release 分支名。如果你的版本号体系独立于分支名，请在这里手动改成规范里的版本号，不要直接回车跳过。
5. 发布流程与常见问题排查：五个我遇到过真实的合并翻车现场
5.1 发布 Release 的标准动作：从 release finish 到推送 tag
规范里整理的发布 Release 流程只有三条命令，但执行顺序有讲究，先执行 git flow release finish，再执行 git push --all 和 git push --tags，是为了确保 finish 过程产生的本地 tag 和分支全部推送到远端，避免远端 master 有代码但 tag 没推上去的情况。
# 先切到 release 分支 git checkout release/material-add # 完成 release：合并到 master、合并回 develop、打 tag git flow release finish material-add # 推送给所有分支和标签 git push --all git push --tagsgit push --all 会推送所有本地分支，这里要留个心眼：如果你本地有临时创建又忘了删除的分支，也会一并推上去，所以发布前先执行 git branch 检查本地分支列表是否干净。
5.2 发布 Hotfix 的标准动作：先 master 后 develop
Hotfix 的发布顺序与 Release 类似，区别在于 finish 之前你要确认当前所在分支上只有要上线的修复内容，不要夹带开发中的半成品：
git checkout hotfix/payment-callback-500 git flow hotfix finish payment-callback-500 git push --all git push --tagsgit flow hotfix finish 会自动把 hotfix 分支合并到 master 和 develop，并且打上 tag。需要注意的一点是，如果在此之前 develop 分支有过大量提交，hotfix 合并回 develop 时可能会产生冲突，这是正常现象，手动解决冲突并提交即可，不要因此跳过合并回 develop 的步骤。
5.3 避坑记录：五类真实问题复盘
下面五条都是我在实际执行这套流程时踩过的坑，按现象、原因、解决三步记录。
现象 1：新同事从 master 拉 feature 分支开发，合并回 develop 时冲突特别多。
原因：master 只保留已发布的代码，它和 develop 之间存在大量未发布的特性差异，基于 master 开发等于把旧基线重新合并一次，冲突面被放大。
解决：规范里明确所有功能分支从 develop 创建，并且开发前先 git pull origin develop 确保基线最新。我后来要求团队所有人创建分支前必须执行这一步，不接受「我本地有旧代码」的理由。
现象 2：测试在 release 分支发现问题，修复完却没人合并回 develop，下个版本又出同样的问题。
原因：release 分支测试期修复的 bug 只存在于 release 分支，develop 分支里这个 bug 仍然存在，下次从 develop 拉取新版本时问题复现。
解决：把「release 合并回 develop」写进上线检查单，和「合并 master、打 tag」并列，完成一项勾一项。git flow release finish 会自动执行合并回 develop，但手工流程必须靠检查单兜底。
现象 3：hotfix 直接在主分支（master）上改，改完忘了合并回 develop。
原因：线上事故紧张时，优先保证线上恢复，hotfix 合并回 develop 的同步动作会后置，后置就容易忘。
解决：hotfix 分支从 master 创建，修完先合并 master 上线，然后立刻切到 develop 执行合并，不要隔夜。git flow hotfix finish 一步到位，如果不用 git flow，就约定 hotfix 修复必须带「master+develop 双 merge」的完成标准。
现象 4：release 和 develop 合并方向反了——把 develop 合到了 release 分支里。
原因：开发人员习惯性在 release 分支上执行 merge develop，想把测试发现的问题修复后同步过来，结果把 develop 上未完成的功能也合进了 release。
解决：release 分支测试期只能通过直接提交修复代码，不能把 develop 合并回来。develop 的功能合入走的是 feature 分支 finish 流程，两条线不要交叉。判断依据很简单：release 分支的内容必须始终是「将要上线的那一套」，不能被非发布内容污染。
现象 5：分支删除不及时，远端残留一堆 feature/xxx 和 bugfix/xxx。
原因：git flow feature finish 会自动删除本地和远端分支，但手工合并流程里，很多人合并完就不记得删远端分支。
解决：每次合并完成我都有意识地执行 git push origin --delete 分支名 + git branch -d 分支名。可以用 git branch -a 列出所有分支，凡是已经不存在的需求单对应的分支，都清理掉。这个习惯坚持下来，远端分支列表基本保持干净。
6. 验证合并是否真的成功：git log 与分支清理的三个小习惯
发布完成后，很多人习惯直接看 Jenkins 构建结果或测试环境链接，很少有人会回头看本地分支状态。但合并是否真正生效、代码有没有漏推，其实从 git 的输出里一眼就能看出来。我每次发布后都会固定走一遍这三个检查动作。
第一个习惯是查看合并历史。git log 的 --graph 参数能直观看到分支的合并轨迹，--oneline 让每条提交只显示一行：
git log --oneline --graph --decorate --all -10执行后会看到类似这样的输出：
* a1b2c3d (HEAD -> master, tag: v1.0.1) Merge branch 'hotfix/payment-callback-500' |\ | * 4e5f6a7 fix: 修复支付回调 500 错误 |/ * 3d4e5f6 (develop) feat: 新增商品到物料库如果发布的是一个 hotfix，master 上应该能看到一条独立的合并节点，hotfix 分支没有残留在图上。如果发布的是 release，则能看到 master 和 develop 各自都收到了 release 分支的合并。检查这一步比看 Jenkins 构建日志更能发现问题——构建成功只代表代码能跑，不代表合并方向是对的。
第二个习惯是清理已经合并过的分支。git branch 的 --merged 参数可以列出所有已经合并到当前分支的本地分支：
git branch --merged凡是列出来的分支，只要不是 master 或 develop，都可以安全删除。配合远端分支清理，我通常用下面的命令检查是否有远端残留：
git branch -r --merged这里有个细节：git branch --merged 判断的是「是否已合并到当前分支」，所以执行前要先保证你在正确的分支上。我一般在 develop 分支执行这个命令，因为 develop 接收了所有 feature 和 bugfix，在它上面执行 --merged 最有参考价值。
第三个习惯是核对 tag。发布过的版本必须能从 tag 找到，这直接决定了线上出问题时能不能快速回滚。用 git tag 查看所有 tag，用 git show 查看某个 tag 对应的提交信息：
git tag git show v1.0.1git show v1.0.1 会输出这个 tag 指向的提交、提交说明、变更文件列表。我每次上线后都会执行这两个命令，确认 tag 存在、并且它指向的提交就是 release 或 hotfix 的合并结果。少了这个确认，你可能直到要回滚时才发现 tag 根本没有推到远端，那就只能靠 git log 猜哪一次提交是发布点了。
我发现自从养成了「发布后先跑一遍 git log --graph，再 git branch --merged 清理，再 git tag 确认」这个固定动作之后，因为合并方向错误和分支残留导致的线上问题基本绝迹了。这套习惯配合前面讲的分支规范与 git flow 工具，让整个团队的合入动作变得可验证、可回溯。希望帮到你。
本文还有配套的精品资源，点击获取
