简介面向开发团队的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-addbugfixJira 单号 MATERIAL-1 对应的 bugbugfix/MATERIAL-1hotfix线上支付回调报错紧急修复hotfix/payment-callback-500提示feature 分支命名不要用编号比如 feature/1、feature/2这类名字在分支多的时候完全无法检索。3. release 与 hotfix两条最容易被合并错方向的短命分支3.1 release 分支从 develop 长出最终同时合并回 master 和 developrelease 分支在规范里的定位是「预发布分支」它从 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 flowmacOS 下可以用 git-flow-avh 项目安装。初始化时执行 git flow initgit 会引导你确认各分支前缀$ 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、finishfeature 分支对应的 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 而不是 developgit 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 后 developHotfix 的发布顺序与 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但手工流程必须靠检查单兜底。现象 3hotfix 直接在主分支master上改改完忘了合并回 develop。原因线上事故紧张时优先保证线上恢复hotfix 合并回 develop 的同步动作会后置后置就容易忘。解决hotfix 分支从 master 创建修完先合并 master 上线然后立刻切到 develop 执行合并不要隔夜。git flow hotfix finish 一步到位如果不用 git flow就约定 hotfix 修复必须带「masterdevelop 双 merge」的完成标准。现象 4release 和 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: 新增商品到物料库如果发布的是一个 hotfixmaster 上应该能看到一条独立的合并节点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 工具让整个团队的合入动作变得可验证、可回溯。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/4 7:34:01 · 阅读 1.2k Git分支管理规范：六类分支职责、合并方向与git flow落地指南
简介面向开发团队的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-addbugfixJira 单号 MATERIAL-1 对应的 bugbugfix/MATERIAL-1hotfix线上支付回调报错紧急修复hotfix/payment-callback-500提示feature 分支命名不要用编号比如 feature/1、feature/2这类名字在分支多的时候完全无法检索。3. release 与 hotfix两条最容易被合并错方向的短命分支3.1 release 分支从 develop 长出最终同时合并回 master 和 developrelease 分支在规范里的定位是「预发布分支」它从 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 flowmacOS 下可以用 git-flow-avh 项目安装。初始化时执行 git flow initgit 会引导你确认各分支前缀$ 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、finishfeature 分支对应的 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 而不是 developgit 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 后 developHotfix 的发布顺序与 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但手工流程必须靠检查单兜底。现象 3hotfix 直接在主分支master上改改完忘了合并回 develop。原因线上事故紧张时优先保证线上恢复hotfix 合并回 develop 的同步动作会后置后置就容易忘。解决hotfix 分支从 master 创建修完先合并 master 上线然后立刻切到 develop 执行合并不要隔夜。git flow hotfix finish 一步到位如果不用 git flow就约定 hotfix 修复必须带「masterdevelop 双 merge」的完成标准。现象 4release 和 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: 新增商品到物料库如果发布的是一个 hotfixmaster 上应该能看到一条独立的合并节点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 工具让整个团队的合入动作变得可验证、可回溯。希望帮到你。本文还有配套的精品资源点击获取