name: git-workflow description: 现代Git团队协作模式 - 分支策略、PR工作流程、提交规范、代码审查实践、仓库加固、CI合并队列、发布/热修复以及合并/变基冲突解决

Git 工作流程（现代团队协作）

使用现代Git协作模式：GitHub Flow用于持续部署，主干开发用于扩展，Conventional Commits用于自动化，堆叠差异用于大型功能。

使用此技能选择分支模型，标准化PR纪律，强制执行提交规范，并加固仓库设置以确保安全协作。

快速开始

识别约束（团队规模、发布节奏、CI成熟度、合规性）。
使用决策树选择分支策略。
应用基线仓库设置（分支保护、批准、检查、合并策略）。
使用相关参考文档获取实现细节。
如果被问及“2026年最佳实践”，请使用data/sources.json作为起始源列表通过网络搜索验证。

快速参考

任务	工具/命令	何时使用	参考
创建功能分支	`git switch -c feat/name main`	开始新工作	分支策略
压缩WIP提交	`git rebase -i HEAD~3`	在PR前清理	交互式变基
规范提交	`git commit -m "feat: add feature"`	所有提交	提交规范
安全强制推送	`git push --force-with-lease`	变基后	常见错误
解决冲突	`git mergetool`	合并冲突	冲突解决
创建堆叠PR	`gt create stack-name` (Graphite)	大型功能	堆叠差异
自动生成变更日志	`npx standard-version`	发布前	发布管理
运行质量门控	GitHub Actions / GitLab CI	每个PR	自动化质量门控

决策树：选择分支策略

使用此决策树根据团队规模、发布节奏和CI/CD成熟度选择最优分支策略。

团队特征 -> 您的情况是什么？
    ├─ 小团队（1-5名开发者）+ 持续部署 + 高CI/CD成熟度？
    │   └─ GitHub Flow（主分支 + 功能分支）
    │
    ├─ 中等团队（5-15名开发者）+ 持续部署 + 高CI/CD成熟度？
    │   └─ 主干开发（主分支 + 短寿命分支）
    │
    ├─ 大团队（15+名开发者）+ 持续部署 + 非常高CI/CD成熟度？
    │   └─ 主干开发 + 功能标志（渐进式推出）
    │
    ├─ 计划发布 + 中等CI/CD成熟度？
    │   └─ GitFlow（主分支 + 开发分支 + 发布分支）
    │
    └─ 多个版本 + 低-中等CI/CD成熟度？
        └─ GitFlow（长寿命发布分支）

导航：核心工作流程

分支策略

分支策略比较 - 选择和实施分支策略的综合指南

GitHub Flow（推荐给现代团队）：简单，持续部署
主干开发（企业规模）：短寿命分支，每日合并
GitFlow（结构化发布）：计划发布，多个版本
决策矩阵：团队规模、发布节奏、CI/CD成熟度
策略间迁移路径

拉取请求最佳实践

PR最佳实践指南 - 有效的代码审查和快速PR周期

PR大小指南：保持PR可审查（通常200-400 LOC效果良好；拆分较大更改）
审查类别：BLOCKER, WARNING, NITPICK
审查礼仪：协作反馈，代码示例
PR描述模板：什么、为什么、如何、测试
基于数据的审查效率见解

提交规范

Conventional Commits标准 - 提交消息格式和语义版本控制集成

规范提交格式：type(scope): description
提交类型：feat, fix, BREAKING CHANGE, refactor, docs
SemVer自动化：从提交自动增加版本
变更日志生成：从提交历史自动化
工具：commitlint, semantic-release, standard-version

导航：高级技术

堆叠差异

堆叠差异实现 - 平台特定工作流程和团队采用

什么是堆叠差异：将大型功能分解为可审查的块
何时使用：功能 > 500行，复杂重构
GitLab原生支持：MR链
GitHub与Graphite：基于CLI的堆叠
好处：审查周期快60%，质量更好

交互式变基

交互式变基与历史清理 - 维护干净的提交历史

自动压缩工作流程：fixup! 和 squash! 提交
交互式变基命令：pick, reword, edit, squash, fixup, drop
拆分提交：将大提交分解为专注的更改
重新排序提交：逻辑提交历史
最佳实践：永远不要变基公共分支

冲突解决

冲突解决技术 - 合并策略和冲突处理

解决策略：--ours, --theirs, 手动合并
变基 vs 合并：何时使用每种
合并工具设置：VS Code, Meld, 自定义工具
冲突标记：理解 <<<<<<<, =======, >>>>>>>
预防策略：频繁变基，小PR

导航：自动化与质量

自动化质量门控

自动化质量门控 - CI/CD管道和质量执行

基本门控：测试、覆盖率、代码检查、安全扫描
高级门控：性能基准、包大小、无障碍检查
GitHub Actions工作流程：完整的PR检查管道
GitLab CI管道：MR质量门控
预提交钩子：Husky + lint-staged 设置
质量指标阈值：覆盖率80%，复杂度 < 10

验证检查清单

验证检查清单 - 预PR、预合并、预发布检查清单

创建PR前：代码质量、提交卫生、测试
合并PR前：审查过程、CI/CD检查、最终验证
发布前：预发布测试、版本管理、文档
部署后：立即验证、监控、任务
热修复检查清单：关键错误快速处理流程

发布管理

发布管理 - 版本控制和部署工作流程

语义版本控制：MAJOR.MINOR.PATCH
手动发布工作流程：GitFlow发布分支
自动化发布：semantic-release自动化
热修复工作流程：紧急补丁
变更日志生成：Keep a Changelog格式
发布检查清单：预发布、发布日、发布后

导航：学习与故障排除

常见错误

常见错误与修复 - 从常见陷阱中学习

大型无重点PR -> 拆分为堆叠差异
模糊提交消息 -> 使用规范提交
重写公共历史 -> 永远不要变基主分支
忽略审查评论 -> 处理所有反馈
提交密钥 -> 使用环境变量
强制推送危险 -> 使用 --force-with-lease

决策表

何时使用每种分支策略

需求	GitHub Flow	主干开发	GitFlow
持续部署	[OK] 最佳	[OK] 最佳	[FAIL] 差
计划发布	[WARNING] 可接受	[WARNING] 可接受	[OK] 最佳
多个版本	[FAIL] 差	[FAIL] 差	[OK] 最佳
小团队 (< 5)	[OK] 最佳	[WARNING] 可接受	[FAIL] 过度
大团队 (> 15)	[WARNING] 可接受	[OK] 最佳	[WARNING] 可接受
快速迭代	[OK] 最佳	[OK] 最佳	[FAIL] 差

PR大小 vs 审查时间

LOC	审查时间	错误检测	推荐
< 50	< 10分钟	高	[OK] 热修复的理想选择
50-200	10-30分钟	高	[OK] 功能的理想选择
200-400	30-60分钟	中-高	[OK] 可接受
400-1000	1-2小时	中	[WARNING] 考虑拆分
> 1000	> 2小时	低	[FAIL] 总是拆分

做 / 避免

好：做

保持PR在400行以下（200-400最优）
使用规范提交消息
在打开PR前变基（干净历史）
合并前需要至少一个批准
在每个PR上运行CI检查
对大型功能使用堆叠差异 (>500 LOC)
合并前压缩WIP提交
使用 --force-with-lease（而不是 --force）

坏：避免

长寿命功能分支 (>3天)
未经审查合并
变基公共/共享分支
强制推送到主分支
提交密钥（即使是“暂时”）
大型单体PR (>1000行)
模糊提交消息（“修复”、“更新”）
跳过CI以更快合并

反模式

反模式	问题	修复
长寿命分支	合并冲突，陈旧代码	主干开发，短分支
未经审查的合并	错误到达生产	分支保护规则
变基主分支	历史损坏	永远不要变基公共分支
1000+ LOC PRs	审查质量差	堆叠差异，拆分PR
“修复”提交	不清晰历史	规范提交
无CI门控	主分支损坏	必需状态检查
历史中的密钥	安全漏洞	预提交钩子，gitleaks

仓库基线（安全 + 可靠性）

在扩展团队前设置这些仓库默认值：

分支保护：要求对main的PR（无直接推送），要求状态检查，要求合并前分支最新。
审查门控：要求批准；对敏感路径（认证、支付、基础设施、生产配置）强制执行CODEOWNERS。
历史策略：选择合并策略（压缩 vs 合并提交）并保持一致性；记录例外。
签名更改：要求发布时签名提交和签名标签（团队特定密钥管理）。
密钥预防：本地预提交 + 服务器端密钥扫描/推送保护；事件发生时轮换。
合并安全：使用合并队列（或等效）以在高并发下保持main绿色。
成本控制：缓存依赖/构建；有条件运行繁重作业；为不受信任分支限制CI分钟数。

模板： assets/pull-requests/pr-template.md 指南： assets/template-git-workflow-guide.md

安全敏感更改

对于安全相关的git操作，请参阅 git-commit-message/assets/template-security-commits.md：

使用预提交钩子检测密钥
处理意外提交的密钥
安全提交元数据（CVE, CVSS）
安全敏感代码的分支保护

可选：AI/自动化

注意：AI工具辅助但不能替代合并决策的人类判断。

PR总结 - 从提交生成描述
变更风险标签 - 标记高风险文件（认证、支付）
审查建议 - 识别潜在审查者

有限声明

AI总结需要人类验证
风险标签是建议，不是保证
合并决策总是需要人类批准

使用说明

对于Claude Code：

推荐GitHub Flow给大多数现代团队（简单，有效）
对功能 > 500行建议堆叠差异
总是验证提交消息符合规范提交格式
检查PR大小 - 如果 > 400行警告，如果 > 1000行阻止
参考assets/以获取可复制粘贴的配置
使用references/以获取深入实现指导

渐进披露：

从快速参考开始以快速查找
使用决策树选择策略
导航到特定资源以获取详细实现
参考模板以获取生产就绪配置
在PR/合并/发布前检查验证检查清单

快速命令参考

常见操作：

# 变基功能分支
git fetch origin && git rebase origin/main

# 交互式变基最后3个提交
git rebase -i HEAD~3

# 压缩分支中所有提交
git rebase -i $(git merge-base HEAD main)

# 安全强制推送
git push --force-with-lease origin feature-branch

# 撤销最后一次提交（保留更改）
git reset --soft HEAD~1

# 挑选特定提交
git cherry-pick abc123

# 储藏更改
git stash push -m "WIP: 实现功能 X"
git stash pop

冲突解决：

# 拉取最新并变基
git pull --rebase origin main

# 使用可视化合并工具
git mergetool

# 接受他们的更改
git checkout --theirs <file>

# 接受您的更改
git checkout --ours <file>

趋势意识协议

重要：当用户询问关于Git工作流程、分支策略或协作工具的建议问题时，请在回答前通过网络搜索（和/或data/sources.json中的链接）验证当前趋势。

触发条件

“什么是[团队规模/用例]的最佳Git工作流程？”
“我应该使用什么进行[分支/PR管理]？”
“Git协作的最新动态是什么？”
“[分支/代码审查]的当前最佳实践？”
“[GitFlow/主干开发]在2026年仍然相关吗？”
“[GitHub Flow] vs [主干开发] vs [GitFlow]？”
“最佳PR堆叠工具？”

必需搜索

搜索："Git 工作流程最佳实践 2026"
搜索："[特定策略] vs 替代方案 2026"
搜索："Git 协作趋势 2026年1月"
搜索："[分支/PR工具] 比较 2026"

报告内容

搜索后，提供：

当前格局：现在流行的Git工作流程/工具是什么
新兴趋势：获得关注的新协作模式、工具或实践
过时/下降：失去相关性或支持的策略/工具
推荐：基于新鲜数据，不仅仅是静态知识

示例主题（用新鲜搜索验证）

分支策略（主干开发、GitHub Flow、GitFlow）
PR堆叠工具（Graphite、git-stack、Stacked PRs）
合并队列实现（GitHub、GitLab）
代码审查平台和自动化
规范提交和变更日志工具
Git托管平台功能（GitHub、GitLab、Bitbucket）
AI辅助Git工作流程

Git现代团队协作工作流程 git-workflow