git-workflow

用途

Git Workflow 技能用于管理 Git 操作，遵循最佳实践，生成有意义的提交信息、安全地管理分支、创建全面的 Pull Request，并防止常见的 Git 错误。

激活触发条件

当用户说出以下内容时激活此技能：

• "commit my changes"
• 提到 "create a branch"
• 要求 "create a PR" 或 "pull request"
• 说出 "push to remote"
• 在任何破坏性 Git 操作之前
• 提到 git 或版本控制

主要能力

1. 智能提交

目标：生成有意义、一致的提交信息，解释变更的原因（WHY）。

流程：

1. 分析变更 — 运行 git status 和 git diff
2. 理解意图 — 添加/修改/删除了什么？解决了什么问题？
3. 生成提交信息，格式为：[type]: [简洁的现在时描述]

提交类型：

• feat 或 feature — 新功能
• fix — Bug 修复
• refactor — 不改变行为的代码重构
• test — 添加或更新测试
• docs — 文档变更
• chore — 维护任务（依赖、配置等）
• style — 代码格式化（无逻辑变更）
• perf — 性能改进

信息指南：

• 现在时、祈使语气（"Add" 而非 "Added"）
• 关注 WHAT 和 WHY，而非 HOW
• 首行不超过 72 个字符
• 结尾不加句号

良好示例：

• feat: Add RSI indicator to market analysis
• fix: Handle division by zero in position sizing
• refactor: Extract strategy validation into separate function

避免：模糊信息（"updated files"）、过去时（"Added new stuff"）或非描述性（"WIP"、"asdfgh"）。

展示并确认 — 呈现建议的信息、文件列表，并请求批准。

执行并验证 — 暂存文件、提交，用 git log -1 --oneline 验证。

2. 分支管理

命名规范：[type]/[description]

类型	用途	示例
feature/	新功能	feature/user-authentication
fix/	Bug 修复	fix/login-timeout-error
refactor/	代码重构	refactor/payment-processing
experiment/	实验性工作	experiment/ml-price-prediction
hotfix/	紧急生产修复	hotfix/security-vulnerability

关键操作：

• 创建：git switch -c feature/name
• 切换：git switch feature/name
• 列出：git branch -v（或 -a 查看远程）
• 删除（安全）：git branch -d feature/old
• 删除远程：git push origin --delete feature/old

安全：在推送到 main/master 之前，警告用户并建议创建功能分支并通过 PR 合并。

3. Pull Request 创建

流程：

1. 分析所有提交：git log main..HEAD --oneline 和 git diff main...HEAD
2. 审查变更 — 整体目的、关键变更、破坏性变更、测试需求
3. 使用以下模板生成 PR 描述：

## Summary
[Brief overview of what this PR does and why]

## Changes
- [Key change 1]
- [Key change 2]

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed

## Code Quality
- [ ] Follows project style guidelines
- [ ] Self-review completed
- [ ] No debug code left
- [ ] Documentation updated

## Related Issues
Closes #[issue number]

1. 创建 PR：使用 gh pr create --title "[Type]: Brief description" --body "..."
2. 返回 PR URL 及后续步骤（请求审查者、监控 CI、处理反馈）

4. 安全检查

提交前：

• 无密钥 — 扫描暂存变更中的 api_key、secret、password、token。如果发现，警告并建议使用 .gitignore 或环境变量。默认中止。
• 测试通过 — 运行测试套件。如果测试失败，阻止提交。
• 大提交警告 — 如果变更 10 个以上文件，建议拆分为更小的提交。

推送前：

• 分支检查 — 如果在 main/master 上，警告并建议功能分支 + PR 工作流。
• 强制推送警告 — 如果检测到 --force，发出严重警告，说明历史重写、工作丢失和 PR 损坏的风险。需要明确确认。

合并前：

• 检查冲突：git merge --no-commit --no-ff [branch] 然后 git merge --abort
• 验证 CI 状态：gh pr checks
• 确认审批：gh pr view --json reviews

工作流示例：防止危险操作

用户："Push my changes to main"

响应：

1. 检测当前分支是 main
2. 警告风险：无代码审查、可能破坏生产、无 CI 门禁
3. 建议：创建功能分支、推送到那里、创建 PR、获取审查
4. 提供替代方案：(1) 创建分支 + PR，(2) 运行测试后推送，(3) 取消

集成点

• 与 review 技能配合进行提交前审查
• 与 spec-driven-implementation 技能配合在执行期间生成提交信息
• 与 systematic-testing 技能配合在提交前验证测试

最佳实践

• 经常提交 — 小而频繁的提交优于大而稀少的提交
• 每次提交一个关注点 — 每个提交代表一个逻辑变更
• 写好信息 — 未来的你会感谢现在的你
• 推送前审查 — 始终先审查自己的变更
• 使用分支 — 永远不要直接在 main 上工作
• 创建 PR — 始终使用 Pull Request，即使是个人项目
• 保持历史干净 — 有意义的提交，而非 "WIP" 或 "fix"

备注

• 始终优先考虑安全而非便利
• 有疑问时默认选择更安全的选项
• 通过清晰的警告防止破坏性操作
• 让做正确的事变得容易