
目录
- 前置知识
- [GitHub Flow 简介](#GitHub Flow 简介)
- 核心原则
- 完整流程架构图
- 开源协作
- [Gitlab flow](#Gitlab flow)
- 常见Git工作流的区别
前置知识
本文将假设你已经掌握了 Git 的基本使用方式。如果你还没有掌握 Git 的基本使用方式,本文或许不适合你,你应该先掌握学习 Git,这对后续的学习很重要。你可以在这里学习它。
GitHub Flow 简介
GitHub Flow 是一种
轻量级、以Pull Request和持续部署为核心的 Git 工作流。它由 GitHub 推广,核心思想是:main 分支始终可部署;所有改动都通过短生命周期分支 + Pull Request 合并回 main;合并后尽快部署。
相较于传统 Git Flow 工作流简单很多,没有 develop、release、hotfix 等长期分支,适合持续交付、持续部署的 Web 应用、SaaS、API 服务和开源项目。
核心原则
开发者规范
main分支永远是只读的- 基于
最新提交开发- 每个功能、修复、文档改动都从最新的 main 拉出独立分支
- 功能分支名要有语义性,例如:
- feature/user-login
- fix/payment-timeout
- hotfix/security-patch
- docs/api-readme
- chore/update-deps
- ...
- 频繁推送提交到远程
- 分支不是本地私有的,尽早推送可以备份、协作、触发 CI。
- 通过 Pull Request 合并
管理员规范
- main 分支只能
通过 PR 修改 - main 分支始终可部署
- main 是唯一长期分支。任何时刻,main 上的代码都应该能通过测试、构建并部署到生产。
- PR 永远
无冲突 - 审查和 CI 通过后才合并
- 合并后立即或尽快部署
- 部署后监控,出问题回滚
- 优先用 git revert 生成反向提交,再通过 PR 合并回滚,而不是在共享分支上 git reset。
完整流程架构图
远程仓库与管理员 开发者侧 远程仓库 本地仓库 远程仓库 本地仓库 #mermaid-svg-58AplQH27J3GoYVT{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#0d47a1;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-58AplQH27J3GoYVT .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-58AplQH27J3GoYVT .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-58AplQH27J3GoYVT .error-icon{fill:hsl(25.3846153846, 86.6666666667%, 99.1176470588%);}#mermaid-svg-58AplQH27J3GoYVT .error-text{fill:rgb(0.3, 2.5500000001, 4.2000000001);stroke:rgb(0.3, 2.5500000001, 4.2000000001);}#mermaid-svg-58AplQH27J3GoYVT .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-58AplQH27J3GoYVT .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-58AplQH27J3GoYVT .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-58AplQH27J3GoYVT .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-58AplQH27J3GoYVT .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-58AplQH27J3GoYVT .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-58AplQH27J3GoYVT .marker{fill:#1e88e5;stroke:#1e88e5;}#mermaid-svg-58AplQH27J3GoYVT .marker.cross{stroke:#1e88e5;}#mermaid-svg-58AplQH27J3GoYVT svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-58AplQH27J3GoYVT p{margin:0;}#mermaid-svg-58AplQH27J3GoYVT .actor{stroke:#1e88e5;fill:#e3f2fd;}#mermaid-svg-58AplQH27J3GoYVT text.actor>tspan{fill:#0d47a1;stroke:none;}#mermaid-svg-58AplQH27J3GoYVT .actor-line{stroke:#90caf9;}#mermaid-svg-58AplQH27J3GoYVT .innerArc{stroke-width:1.5;stroke-dasharray:none;}#mermaid-svg-58AplQH27J3GoYVT .messageLine0{stroke-width:1.5;stroke-dasharray:none;stroke:#1e88e5;}#mermaid-svg-58AplQH27J3GoYVT .messageLine1{stroke-width:1.5;stroke-dasharray:2,2;stroke:#1e88e5;}#mermaid-svg-58AplQH27J3GoYVT #arrowhead path{fill:#1e88e5;stroke:#1e88e5;}#mermaid-svg-58AplQH27J3GoYVT .sequenceNumber{fill:#ffffff;}#mermaid-svg-58AplQH27J3GoYVT #sequencenumber{fill:#1e88e5;}#mermaid-svg-58AplQH27J3GoYVT #crosshead path{fill:#1e88e5;stroke:#1e88e5;}#mermaid-svg-58AplQH27J3GoYVT .messageText{fill:#0d47a1;stroke:none;}#mermaid-svg-58AplQH27J3GoYVT .labelBox{stroke:#43a047;fill:#e8f5e9;}#mermaid-svg-58AplQH27J3GoYVT .labelText,#mermaid-svg-58AplQH27J3GoYVT .labelText>tspan{fill:#1b5e20;stroke:none;}#mermaid-svg-58AplQH27J3GoYVT .loopText,#mermaid-svg-58AplQH27J3GoYVT .loopText>tspan{fill:#1b5e20;stroke:none;}#mermaid-svg-58AplQH27J3GoYVT .loopLine{stroke-width:2px;stroke-dasharray:2,2;stroke:#43a047;fill:#43a047;}#mermaid-svg-58AplQH27J3GoYVT .note{stroke:#ffb300;fill:#fff8e1;}#mermaid-svg-58AplQH27J3GoYVT .noteText,#mermaid-svg-58AplQH27J3GoYVT .noteText>tspan{fill:#5d4037;stroke:none;}#mermaid-svg-58AplQH27J3GoYVT .activation0{fill:#bbdefb;stroke:#1976d2;}#mermaid-svg-58AplQH27J3GoYVT .activation1{fill:#bbdefb;stroke:#1976d2;}#mermaid-svg-58AplQH27J3GoYVT .activation2{fill:#bbdefb;stroke:#1976d2;}#mermaid-svg-58AplQH27J3GoYVT .actorPopupMenu{position:absolute;}#mermaid-svg-58AplQH27J3GoYVT .actorPopupMenuPanel{position:absolute;fill:#e3f2fd;box-shadow:0px 8px 16px 0px rgba(0,0,0,0.2);filter:drop-shadow(3px 5px 2px rgb(0 0 0 / 0.4));}#mermaid-svg-58AplQH27J3GoYVT .actor-man line{stroke:#1e88e5;fill:#e3f2fd;}#mermaid-svg-58AplQH27J3GoYVT .actor-man circle,#mermaid-svg-58AplQH27J3GoYVT line{stroke:#1e88e5;fill:#e3f2fd;stroke-width:2px;}#mermaid-svg-58AplQH27J3GoYVT .messageLine0{stroke:#1e88e5!important;stroke-width:2px;}#mermaid-svg-58AplQH27J3GoYVT .messageLine1{stroke:#fb8c00!important;stroke-width:2px;}#mermaid-svg-58AplQH27J3GoYVT .messageText{fill:#0d47a1!important;}#mermaid-svg-58AplQH27J3GoYVT .rect,#mermaid-svg-58AplQH27J3GoYVT .box{stroke:transparent!important;stroke-width:0!important;}#mermaid-svg-58AplQH27J3GoYVT .background{fill:transparent!important;}#mermaid-svg-58AplQH27J3GoYVT :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 从远程同步最新代码 开发者 管理员 拉取: main 分支 1 开发: 切换分支,多次提交 2 推送: 推送开发分支 3 创建 PR: base main 4 review: 审查 5 提交: 提交合并到 main 分支 6 删除:删除开发分支 7 开发者 管理员
开源协作
协作者流程
- 和管理员开发基本相同,差异点:
- 管理员需要添加协作者
- PR 时必须 review
-
非协作者(陌生人)流程
- 前置工作:
-
Fork 仓库
-
克隆 Fork 仓库
-
添加上游源仓库源
-
bash# 添加上游 git remote add upstream https://github.com/原作者/仓库名.git # 查看远程源(确认 origin 是你的 Fork,upstream 是原仓库) git remote -v- 贡献流程
- 拉取最新代码
- 前置工作:
bash
git switch main
git fetch upstream
git merge upstream/main
# 推回自己的 Fork,保证三方最新同步
git push origin main
- 功能分支完成后,提交 PR,需要到自己仓库主页提交 PR
Gitlab flow
gitlab flow,其实和github flow没有本质上的区别,只不过是增加了几个多环境。GitLab Flow 并非对 GitHub Flow 的颠覆,而是一种务实的扩展。它在保留 GitHub Flow 核心简洁性的同时,引入了应对复杂部署场景的机制,核心区别在于:GitHub Flow 假设"主干即生产",而 GitLab Flow 认为"主干是上游,生产是下游"。
- 主要变化点:新增了,生产分支,和预发布分支的流程

常见Git工作流的区别
| 维度 | Git Flow(传统) | GitHub Flow(极简迭代) | GitLab Flow(企业级均衡) |
|---|---|---|---|
| 核心假设 | 版本化发布,发布周期较长,需要严格的发布准备 | main 始终可部署,合并即可发布 |
main 是上游,生产是下游;合并与发布解耦 |
| 长期分支 | main + develop |
仅 main |
main + 环境分支(如 pre-prod、production),可选发布分支 |
| 临时/支持分支 | feature/*、release/*、hotfix/* |
feature/*(短生命周期) |
feature/*(短生命周期) |
| 分支流向 | feature → develop;release → main + develop;hotfix → main + develop | feature → main | feature → main;main → 下游环境分支;发布分支由 main 派生 |
| 发布方式 | 通过 release 分支准备,合并到 main 并打 tag |
合并到 main 即部署/可部署 |
合并到 main 后,按需推进到 pre-prod、production 等环境分支 |
| 环境管理 | 不直接绑定环境,靠 release 流程和外部工具 | 无内置环境分支,通常单生产环境 | 用环境分支显式管理多环境 |
| 热修复/Bug 修复 | 从 main 拉 hotfix,合回 main 和 develop,再打 tag |
从 main 拉修复分支,合回 main |
上游优先:先在 main 修,再合到下游环境/发布分支;紧急才直接下游 |
| 多版本维护 | 强,可为旧版本保留 release/hotfix 线 | 弱,通常只维护最新版本 | 中强,可用 stable-* 发布分支维护 |
| CI/CD 集成 | 可集成,但分支多,流水线复杂 | 集成简单,合并即部署 | 深度集成,环境分支触发对应部署 |
| 复杂度 | 高 | 低 | 中 |
| 优点 | 发布控制强,适合计划性版本发布 | 简单快速,适合持续部署 | 兼顾简单与多环境,规则明确 |
| 缺点 | 分支多、合并冲突多、不适合持续部署 | 多环境/版本管理弱 | 环境分支同步有额外开销 |
| 适用场景 | 有明确版本号的桌面/移动/企业软件 | Web/SaaS、小团队、持续部署 | 多环境部署、需要发布缓冲、中大型团队 |
一句话总结:Git Flow 偏重版本发布管理,GitHub Flow 偏重持续部署,GitLab Flow 则是两者之间的折中路线,强调多环境和"上游优先"。

🚵♂️ 博主座右铭:向阳而生,我还在路上!
🚴博主想说:将持续性为社区输出自己的资源,同时也见证自己的进步!
🤼♂️ 如果都看到这了,博主希望留下你的足迹!【📂收藏!👍点赞!✍️评论!】