Workflows
Git 工作流频道
把日常协作中的关键流程拆成多个专题，包括同步策略、功能分支协作、评审前同步，以及紧急修复场景。
Workflows
推荐学习顺序
先掌握 fetch 与 pull 的边界，再学习协作、评审前同步和紧急修复的操作顺序。
Workflows
代表专题
这三类专题最能体现工作流频道的价值：同步边界、评审前整理，以及紧急修复时的操作顺序。
Workflows
专题目录
把常见 Git 工作流拆成多个场景化专题，帮助团队把操作顺序和协作边界固定下来。
fetch 与 pull 的区别
解释为什么先 fetch 再决定 merge 或 rebase，往往比直接 pull 更可控。
功能分支协作流
围绕 feature branch 的日常协作流程，整理从切分支、同步主线、提交整理到发起评审的稳定做法。
Gitflow 工作流教程
基于 Atlassian 对 Gitflow 的说明，梳理 main、develop、feature、release、hotfix 的职责，以及它在现代团队中的适用边界。
多人协作时的同步节奏
围绕多人并行开发，建立一套先 fetch、再观察、再整合的同步节奏，减少 pull 惊喜和共享历史误操作。
PR 前如何整理提交历史
在发起 PR 之前，围绕同步、提交整理、风险确认和 review 友好度，建立一套稳定的准备动作。
用 worktree 并行处理多个任务
当你需要同时处理当前功能、紧急修复或评审修改时，用 git worktree 在同一个仓库上开出多个独立工作目录。
AI Coding Agent 下的 git worktree 模式
把 git worktree 变成 AI coding agent 的默认并行工作模式，减少上下文污染、提升回滚安全性，并让多任务协作更清晰。
monorepo 场景下的稀疏检出与多工作树协作
在 monorepo 场景里，用 sparse-checkout 和 worktree 限定工作范围，降低上下文负担并支持并行任务。
用 rerere 处理重复冲突
当同一类冲突反复出现时，用 rerere 记录并复用你的解决结果，减少长期分支和频繁同步里的重复劳动。
多人共享分支的同步边界
当多人同时在同一分支协作时，明确什么动作可以做、什么动作不该做，减少同步混乱和历史覆盖。
评审前同步主线
在发起评审前先同步主线并检查差异范围，减少 reviewer 面对过期基底、重复冲突和历史噪声的成本。
PR 合并策略与平台配置
把 squash merge、rebase merge、merge commit 和平台配置放到同一个决策框架里，帮助团队统一 PR 落地方式。
Merge Queue 工作流
当团队并发合并很多 PR 时，用 merge queue 降低串行抢占主线、重复排队和基底过期的问题。
紧急修复工作流
当线上或发布链路出现高优先级问题时，如何从稳定分支切出 hotfix，快速修复并有序回流主线。
发布后热修失败，如何回滚与稳定主线
当发布后热修本身引入问题时，优先判断回滚粒度、共享影响和后续补丁路径，而不是立刻继续叠加修复。
开源贡献 / fork + PR 完整提交流程
把开源贡献里从 fork、同步上游、切分支、提交改动到发起 PR 的完整节奏串起来。
发布分支工作流教程
梳理何时切发布分支、何时冻结功能、以及如何把修复回流主线。
使用 Cherry-pick 回移修复
把主线上的精确修复回移到维护分支，而不是把整条功能分支或无关历史一起合进去。
发布后多维护线回移策略
当一个修复需要在多个已发布版本之间回移时，如何控制顺序、验证范围和分支边界。
Fork 与上游同步教程
在 fork 模式协作中维持 origin 与 upstream 的清晰边界，稳定同步上游更新，并把自己的改动安全推回个人 fork。
Squash Merge 与 Rebase Merge 选择教程
比较两种常见合并策略对历史可读性、追踪性和回滚方式的影响。
长期分支维护教程
说明长期存在的分支如何同步主线、控制漂移，并减少大爆炸式合并。
长期分支冲突治理
把长期分支里的冲突处理从临时救火升级成可治理的流程，包括同步节奏、冲突热区识别和重复冲突复用。
子模块更新流程教程
梳理子模块仓库更新、锁定版本和主仓库同步的基本流程。
Trunk-Based Development 工作流
用短生命周期分支和高频小批次合并，把主线始终保持在可发布状态，降低长期分叉与集成冲突成本。
Stacked Pull Requests 工作流
把一个大改动拆成有依赖关系的多层 PR，提升评审吞吐与可读性，同时降低一次性大 PR 的认知负担。
回归问题 bisect 排查工作流
当出现“最近坏了但不知道谁改坏的”问题时，用 git bisect 通过二分定位首个坏提交，显著缩短排查路径。
Code Freeze 与 Release Candidate 工作流
在发布前通过代码冻结与 RC 候选流程收敛变更范围，让问题暴露在发布前而不是发布后。
Revert-First 稳定化工作流
线上回归发生时先恢复服务稳定，再分离根因修复；通过 revert-first 策略缩短故障窗口并降低二次事故风险。
Feature Flag 渐进发布工作流
把代码合并与功能放量解耦，利用 feature flag 分阶段上线与回滚，降低大功能一次性发布风险。
Release Train 工作流
以固定节奏发车替代“功能等发布”，通过版本列车机制提高组织可预测性并降低临时插单造成的发布波动。
跨仓库集成工作流
当一个需求跨多个仓库协同落地时，用统一分支命名、集成清单和串联验证流程降低联调失败率。
Canary 发布工作流
通过小流量金丝雀发布逐步验证线上行为，在全量放量前提前暴露风险并降低事故半径。
数据库迁移安全工作流
将数据库 schema 变更拆分为可回退、可观测、可分阶段执行的迁移流程，降低发布期结构变更风险。
API 版本变更工作流
对外 API 发生破坏性变更时，通过并行版本、弃用窗口和迁移治理降低客户端升级成本与兼容事故。
事故复盘到工程护栏工作流
将事故复盘结论转化为可执行的 CI/发布/代码护栏，避免复盘停留在文档层而无法降低未来风险。
发布前的 Git 检查清单
发布前的完整 Git 检查清单：分支状态、tag 创建、changelog 生成、版本号、CI 验证。
CI/CD 中的 Git 优化
CI/CD 中的 Git 优化策略：浅克隆、缓存、partial clone、只拉变更，以及 GitHub Actions / GitLab CI 中的具体配置。
主干开发工作流
主干开发 vs 分支开发对比、feature flag 配合、短分支策略、小步提交实践。
签名提交工作流
使用 GPG 或 SSH 签名提交，建立可验证的提交身份和可信协作链。
提交前检查工作流
利用 pre-commit hook 在代码进入仓库前自动运行检查，守住代码质量第一道关。
大文件处理工作流
使用 Git LFS、稀疏检出和分包策略管理仓库中的大文件，保持克隆速度和历史可维护性。
部署回滚工作流
结合 Git 标签、revert 和快速分支切换，建立安全可控的部署回滚流程。