目录前置知识GitHub 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-loginfix/payment-timeouthotfix/security-patchdocs/api-readmechore/update-deps…频繁推送提交到远程分支不是本地私有的尽早推送可以备份、协作、触发 CI。通过 Pull Request 合并管理员规范main 分支只能通过 PR 修改main 分支始终可部署main 是唯一长期分支。任何时刻main 上的代码都应该能通过测试、构建并部署到生产。PR 永远无冲突审查和 CI 通过后才合并合并后立即或尽快部署部署后监控出问题回滚优先用 git revert 生成反向提交再通过 PR 合并回滚而不是在共享分支上 git reset。完整流程架构图远程仓库与管理员开发者侧远程仓库本地仓库远程仓库本地仓库从远程同步最新代码开发者管理员拉取: main 分支1开发: 切换分支多次提交2推送: 推送开发分支3创建 PR: base main4review: 审查5提交: 提交合并到 main 分支6删除删除开发分支7开发者管理员开源协作协作者流程和管理员开发基本相同差异点管理员需要添加协作者PR 时必须 review非协作者陌生人流程前置工作Fork 仓库克隆 Fork 仓库添加上游源仓库源# 添加上游gitremoteaddupstream https://github.com/原作者/仓库名.git# 查看远程源确认 origin 是你的 Forkupstream 是原仓库gitremote-v贡献流程拉取最新代码gitswitch maingitfetch upstreamgitmerge upstream/main# 推回自己的 Fork保证三方最新同步gitpush origin main功能分支完成后提交 PR需要到自己仓库主页提交 PRGitlab flowgitlab flow其实和github flow没有本质上的区别只不过是增加了几个多环境。GitLab Flow 并非对 GitHub Flow 的颠覆而是一种务实的扩展。它在保留 GitHub Flow 核心简洁性的同时引入了应对复杂部署场景的机制核心区别在于GitHub Flow 假设“主干即生产”而 GitLab Flow 认为“主干是上游生产是下游”。主要变化点新增了生产分支和预发布分支的流程常见Git工作流的区别维度Git Flow传统GitHub Flow极简迭代GitLab Flow企业级均衡核心假设版本化发布发布周期较长需要严格的发布准备main始终可部署合并即可发布main是上游生产是下游合并与发布解耦长期分支maindevelop仅mainmain 环境分支如pre-prod、production可选发布分支临时/支持分支feature/*、release/*、hotfix/*feature/*短生命周期feature/*短生命周期分支流向feature → developrelease → main develophotfix → main developfeature → mainfeature → mainmain → 下游环境分支发布分支由 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 则是两者之间的折中路线强调多环境和“上游优先”。‍♂️ 博主座右铭向阳而生我还在路上——————————————————————————————博主想说将持续性为社区输出自己的资源同时也见证自己的进步——————————————————————————————‍♂️ 如果都看到这了博主希望留下你的足迹【收藏点赞✍️评论】——————————————————————————————