简介这份《分支管理规范-GIT分支流程开发规范》面向使用Git进行团队协作的开发人员尤其是刚加入标准分支流程的新人用于解决分支命名混乱、合并时机不清、发布与热修复流程不统一等问题。资源以doc文档形式交付压缩包内共1个文件约239KB内容围绕master、develop、feature、bugfix、release、hotfix等分支的职责划分与流转规则展开并给出分支命名示例、常用Git操作命令以及git flow工具的简化用法。文档还梳理了发布Release与发布Hotfix两条完整流程说明从develop创建release分支、测试后合并至master并打标签以及从master创建hotfix分支修复线上紧急问题的处理方式。目前已有2176人学习适合希望建立规范化协作流程、减少代码冲突与发布风险的开发团队参考。1. 分支管理规范落地为什么你的团队还在用 master 硬扛上周帮一个朋友看他们团队的仓库git log --graph打出来像一团乱麻master 上直接堆着十几个人的提交线上出了 bug 找不到对应版本回滚全靠git reset --hard赌运气。这不是个例很多研发团队初创时都是「一个 master 走天下」人少的时候没问题人一多、版本一多代码冲突和上线事故就变成玄学。这份《GIT 分支流程开发规范》解决的正是这个问题它定义了一套从 feature 到 release 再到 hotfix 的完整分支模型把「开发、测试、发布、紧急修复」四个阶段和分支一一对应让每个提交都有归属每次上线都有据可查。它适合正在从「小作坊」往「正规军」过渡的研发团队尤其是刚引入 git flow 或者准备统一分支命名规范的新人。下面我按「规范是什么 → 怎么用 git flow 落地 → 坑在哪」的顺序拆一遍中间会给出可直接抄的命令和参数说明。2. 分支模型拆解master、develop 与四类短期分支的职责边界2.1 长期分支只有两个别多开规范里明确写了项目中长期存在的只有master和develop两个分支。master负责记录上线版本的迭代代码与线上完全一致develop记录相对稳定的版本所有 feature 和 bugfix 都从这里创建。这个设计的关键在于「单一可信源」线上是什么状态看 master 就知道下一个版本开发到什么程度看 develop 就知道。很多团队翻车是因为又开了test、uat、pre一堆长期分支结果合并方向乱了最后没人说得清哪个分支对应哪个环境。短期分支有四类完成功能后必须删除分支类型命名格式创建来源合并目标特性分支feature/描述developdevelopbug 修复分支bugfix/编号developdevelop发布分支release/描述developmaster develop紧急修复分支hotfix/描述mastermaster develop这张表建议直接贴到团队 wiki 首页。命名规范不是形式主义feature/material-add和feature/add的区别在于三个月后你还能从分支名看出它干了什么而add你只能去翻 commit。2.2 分支命名规范与创建来源规范对命名给了明确要求功能分支用能准确描述功能的英文简要表述比如「新增商品到物料库」就建feature/material-addbug 修复分支用 Jira 编号或英文简称比如bugfix/MATERIAL-1release 分支用本次发布的主要功能英文简称比如release/material-add。这里有个容易忽略的点bugfix 是从 develop 创建的不是从 master。只有 hotfix 才从 master 创建因为它是修线上已经发布的紧急问题。创建分支的命令本身很简单但来源分支别搞错# 从 develop 创建功能分支正确做法 git checkout develop git pull origin develop git checkout -b feature/material-add # 从 develop 创建普通 bugfix 分支 git checkout develop git checkout -b bugfix/MATERIAL-1 # 只有紧急线上问题才从 master 创建 hotfix git checkout master git pull origin master git checkout -b hotfix/MATERIAL-1git checkout -b的-b参数表示新建并切换等价于git branch name加git checkout name。注意每次创建前先git pull拉最新代码否则你的分支起点是旧的后面合并时冲突会多到怀疑人生。这一步是血泪经验我见过太多人直接在本地旧 develop 上开分支结果 PR 里混进一堆别人的提交。2.3 合并方向与删除时机合并方向是这套规范里最容易出错的地方。feature 和 bugfix 完成后合并回 develop然后删除release 完成后要合并到 master 和 develop 两个分支再删除hotfix 完成后同样要合并到 master 和 develop再删除。注意 release 和 hotfix 都是「双向合并」只合 master 不合 develop下一个版本就会丢掉这次修复线上问题会复发。删除分支的时机是「合并完成后立即删除」本地和远程都要删# 删除本地分支 git branch -d feature/material-add # 删除远程分支 git push origin --delete feature/material-add-d是安全删除如果分支还没合并会报错提醒你如果确定要强删用-D但生产环境慎用。远程删除用git push origin --delete别用git push origin :branch那种老写法容易看花眼。3. 用 git flow 把规范变成命令初始化、feature、release、hotfix 全流程3.1 安装与初始化一次配置长期生效规范里推荐用 git flow 插件来简化操作。Windows 下通过安装包安装的 git 默认已经包含这个插件可以直接用macOS 或 Linux 可以用包管理器装git-flow-avh。装好后在项目根目录执行初始化git flow init执行后会进入交互式问答依次确认各分支前缀。规范里给出的默认值就是我们要的Branch name for production releases: [master] Branch name for next release development: [develop] Feature branches? [feature/] Bugfix branches? [bugfix/] Release branches? [release/] Hotfix branches? [hotfix/] Support branches? [support/] Version tag prefix? []一路回车即可。初始化只做一次它会在.git/config里写入 git flow 的配置之后所有git flow命令都按这套前缀走。如果团队已经有用其他前缀的历史分支初始化时改成对应值否则 git flow 找不到已有分支。3.2 feature 分支从创建到合并的完整命令链规范里给了一段完整的 feature 操作示例我把它拆成可复现的步骤。假设要开发「新增商品到物料库」# 1. 创建并切换到功能分支自动从 develop 拉出 git flow feature start material-add # 输出Switched to a new branch feature/material-add # 2. 推送到远程让协作者能看到 git flow feature publish material-add # 3. 正常开发、提交 vim README.md git add --all git commit -m modify readme file git push # 4. 开发完成合并回 develop 并删除分支 git flow feature finish material-addgit flow feature start背后做了两件事从 develop 创建feature/material-add并切换过去。publish会把本地分支推到远程并建立追踪关系团队协作时这一步不能省否则别人拉不到你的分支。finish会自动切回 develop、合并 feature 分支、删除本地分支如果之前 publish 过还会删除远程分支。注意finish默认用--no-ff合并会生成一个合并提交保留功能分支的历史轨迹这对追溯很有用。3.3 release 与 hotfix发布和紧急修复的标准动作release 分支用于上线前的测试和 bug 修复。创建 release 分支git flow release start material-add这行命令从 develop 创建release/material-add并切换过去。测试同学把它发布到测试环境测试中发现的 bug 由开发直接在这个 release 分支上修复并提交。所有 bug 修完后执行git flow release finish material-add git push --all git push --tagsfinish会做四件事把 release 合并到 master、打上版本 tag、合并回 develop、删除 release 分支。git push --all推送所有分支git push --tags推送标签两条都不能少否则远程仓库看不到新版本 tag。hotfix 用于线上紧急问题从 master 创建git flow hotfix start MATERIAL-1 # 修复代码... git flow hotfix finish MATERIAL-1 git push --all git push --tagshotfix finish同样会合并到 master 和 develop 两边并打 tag。这里有个细节hotfix 的 tag 通常打在 master 上标记这次紧急修复的版本号。规范里强调 hotfix 必须同时合并到 develop 和 master共两次 merge 操作漏掉 develop 的话下个版本发布时这个修复就丢了。4. 避坑与排查分支流程里最容易翻车的五个场景4.1 合并方向搞反develop 丢了修复现象线上 hotfix 修完只合了 master过两周新版本发布同样的 bug 又出现了。原因hotfix 或 release 只做了单向合并develop 没拿到修复代码。解决每次finish后执行git log develop --oneline确认修复提交在 develop 上或者用git branch --contains commit检查提交被哪些分支包含。4.2 在旧 develop 上开分支PR 混入无关提交现象新建的 feature 分支 PR 里出现一堆别人的提交review 时根本看不出你改了什么。原因创建分支前没git pull本地 develop 落后于远程。解决养成「先切 develop、先 pull、再开分支」的固定动作命令顺序不能颠倒。已经开错了就用git rebase develop把分支基点挪到最新。4.3 git flow finish 后远程分支没删掉现象本地分支删了远程feature/xxx还在仓库里堆了几十个僵尸分支。原因finish只删本地分支远程分支需要之前publish过才会自动删或者手动删。解决git push origin --delete feature/xxx手动清理团队约定每周清理一次远程已合并分支。4.4 tag 没推上去发布版本对不上现象release finish打了 tag但远程仓库看不到运维部署时找不到版本号。原因只执行了git push没执行git push --tags。解决发布流程固定为git flow release finishgit push --allgit push --tags三条命令缺一不可。可以用git ls-remote --tags origin验证 tag 是否推成功。4.5 冲突解决后忘了继续 finish现象git flow release finish过程中遇到冲突解决完冲突后命令卡住分支状态不完整。原因合并冲突需要手动git add后git commit然后重新执行 finish 的后续步骤。解决冲突解决后先git status确认所有冲突已标记为 resolved再git commit然后重新跑git flow release finishgit flow 会从中断处继续。如果状态乱了用git flow release finish -k保留分支不删除排查完再手动处理。5. 进阶技巧用 git flow 钩子和分支保护把规范焊死规范靠自觉执行迟早会松最后一章说两个把流程「焊死」的技巧。第一个是 git flow 的 hooks 机制。初始化时最后一项Hooks and filters directory指向.git/hooks你可以在里面放post-flow-feature-start之类的脚本自动在分支创建后往 Jira 或钉钉发通知或者校验分支名是否符合feature/[a-z-]的正则。比如在.git/hooks/post-flow-feature-start里写#!/bin/sh # 校验分支名只含小写字母和连字符 BRANCH$(git rev-parse --abbrev-ref HEAD) if ! echo $BRANCH | grep -qE ^feature/[a-z-]$; then echo 分支名不符合规范$BRANCH应为 feature/小写英文描述 exit 1 fi这个脚本在git flow feature start之后触发命名不合规直接报错退出比事后 review 时提醒有效得多。注意脚本要有可执行权限chmod x .git/hooks/post-flow-feature-start。第二个是远程仓库的分支保护规则。在 GitLab 或 GitHub 上把master和develop设为保护分支禁止直接 push所有变更必须走 merge request。这样即使有人本地忘了走 git flow也推不上去。配合 CI 在 MR 上跑单元测试测试不过不允许合并。我一般还会加一条规则release 和 hotfix 分支的合并必须由指定角色操作避免新人误合。验证整套流程是否跑通可以用一个最小仓库演练一遍初始化 git flow、开 feature、提交、finish、开 release、finish、检查 master 和 develop 是否都有提交、tag 是否推送成功。整个演练十分钟能跑完比看十遍文档管用。从那以后我每次带新团队都强制让每个人在测试仓库里完整走一遍 feature → release → hotfix 的闭环走不通不准碰生产仓库。希望帮到你。本文还有配套的精品资源点击获取