Github Flow 与 Gitlab Flow工作流实践解读

目录

前置知识

本文将假设你已经掌握了 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

  • 非协作者(陌生人)流程

    • 前置工作:
      1. Fork 仓库

      2. 克隆 Fork 仓库

      3. 添加上游源仓库源

    bash 复制代码
    # 添加上游
    git remote add upstream https://github.com/原作者/仓库名.git
    # 查看远程源(确认 origin 是你的 Fork,upstream 是原仓库)
    git remote -v
    • 贡献流程
      1. 拉取最新代码
bash 复制代码
git switch main
git fetch upstream
git merge upstream/main
# 推回自己的 Fork,保证三方最新同步
git push origin main
  1. 功能分支完成后,提交 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-prodproduction),可选发布分支
临时/支持分支 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-prodproduction 等环境分支
环境管理 不直接绑定环境,靠 release 流程和外部工具 无内置环境分支,通常单生产环境 用环境分支显式管理多环境
热修复/Bug 修复 mainhotfix,合回 maindevelop,再打 tag main 拉修复分支,合回 main 上游优先:先在 main 修,再合到下游环境/发布分支;紧急才直接下游
多版本维护 强,可为旧版本保留 release/hotfix 线 弱,通常只维护最新版本 中强,可用 stable-* 发布分支维护
CI/CD 集成 可集成,但分支多,流水线复杂 集成简单,合并即部署 深度集成,环境分支触发对应部署
复杂度
优点 发布控制强,适合计划性版本发布 简单快速,适合持续部署 兼顾简单与多环境,规则明确
缺点 分支多、合并冲突多、不适合持续部署 多环境/版本管理弱 环境分支同步有额外开销
适用场景 有明确版本号的桌面/移动/企业软件 Web/SaaS、小团队、持续部署 多环境部署、需要发布缓冲、中大型团队

一句话总结:Git Flow 偏重版本发布管理,GitHub Flow 偏重持续部署,GitLab Flow 则是两者之间的折中路线,强调多环境和"上游优先"。


🚵‍♂️ 博主座右铭:向阳而生,我还在路上!


🚴博主想说:将持续性为社区输出自己的资源,同时也见证自己的进步!


🤼‍♂️ 如果都看到这了,博主希望留下你的足迹!【📂收藏!👍点赞!✍️评论!】


相关推荐
wangruofeng11 小时前
120+ 个 Agent Skill 管不过来?我造了套「包管理器」:仓库是源,链接是安装
github·aigc·ai编程
七牛云行业应用11 小时前
Cursor Origin发布:同一天GitHub宕机,AI原生代码托管来了
人工智能·github·agent·ai编程·ai-native
xyz_CDragon12 小时前
GitHub上4个爆款AI开源Skill:拍照后不用P图,用Codex一键生成高级海报(附效果图+使用教程)
人工智能·python·github·codex·skill
天若有情67316 小时前
表面普通随机数网页,藏有隐藏后台面板,暗号解锁|Github Pages 在线演示
github
典典分享指南19 小时前
DeepSeek Harness 开源贡献手记:从 Issue 到 Merge 的完整旅程
jupyter·github·vim·idea·visual studio
峰向AI1 天前
坚持不下去?这个 14K Star 的 App 把你的习惯变成 RPG 游戏
github
Bmob后端云1 天前
Bmob后端云实战|Python实现SSE流式输出,给备忘录AI加上打字机效果
前端·github
峰向AI1 天前
还在手动配 SSL 证书?这个 75K Star 的 Web 服务器让 HTTPS 自动到起飞
github
Java陈序员1 天前
轻量运维面板!一款现代化的服务器控制面板工具!
运维·服务器·python·react.js·github