Git Workflows
Use this skill for non-trivial git work where safety, history clarity, or repository structure matters more than a single command.
Keep the main thread focused on the user’s goal. Prefer the smallest safe sequence of git operations.
Core approach
Before suggesting commands, determine:
- 1. the user’s goal
- whether history is already shared with others
- whether the task changes commits, refs, working tree, or repository structure
- whether recovery should be prepared first
If a step is destructive or hard to reverse, create a safety point first.
Default safety rules
- - Check
git status before history edits. - Check the current branch and upstream before rebases, resets, or force-pushes.
- Prefer non-destructive inspection first.
- Prefer
git switch and git restore over older mixed forms when clarity matters. - Create a recovery point before risky history surgery.
- Avoid rewriting shared history unless the user explicitly wants that tradeoff.
- When conflicts or recovery are involved, explain both the immediate fix and the rollback path.
Recovery-first moves
Use these patterns early when risk is high:
CODEBLOCK0
For history recovery, inspect before changing anything:
CODEBLOCK1
Read references/recovery.md for reflog-based recovery, reset recovery, branch recovery, and force-push mistakes.
Common task families
History cleanup
Use for:
- - squashing fix commits
- rewording commit messages
- splitting a bad commit
- dropping accidental commits
- preparing a branch before merge
Prefer interactive rebase for local or not-yet-shared history.
Bug origin hunting
Use git bisect when the user knows a good state and a bad state and needs to find the introducing commit.
Parallel branch work
Use git worktree when the user needs two branches checked out at once, wants cleaner hotfix flow, or wants to avoid stashing.
Conflict handling
Resolve carefully when rebasing, merging, cherry-picking, or applying stashes. Preserve user intent, not just file merge success.
Repository archaeology
Use blame, pickaxe, grep, log graph, and path history when the user needs to answer:
- - who changed this
- when did this break
- where did this line come from
- which commit removed this behavior
Repository shape changes
Use extra care for:
- - submodules
- subtrees
- sparse checkout
- worktree pruning
- branch renames
- default-branch migration
Read references/advanced-patterns.md when the task involves repository topology rather than simple day-to-day commits.
Decision rules
Rebase vs merge
- - Prefer rebase for cleaning local feature-branch history.
- Prefer merge when preserving shared branch history matters.
- If the branch is already shared, explicitly call out the rewrite risk before rebasing.
Subtree vs submodule
- - Prefer subtree when the user wants simpler consumption and fewer contributor footguns.
- Prefer submodule when the user truly needs a pinned external repository boundary.
Worktree vs stash
- - Prefer worktree for medium or long parallel work.
- Prefer stash for short interruptions or tiny context switches.
Reset vs restore vs revert
- - Prefer
restore for file-level undo. - Prefer
reset for local history and index surgery. - Prefer
revert for undoing commits that are already shared.
Operating style
When guiding the user:
- 1. say what state to inspect first
- state the safest command sequence
- note whether history is being rewritten
- give the rollback path when risk is non-trivial
Keep command sets short. Do not dump every git option unless needed.
When to read references
- - Read
references/recovery.md for reflog recovery, accidental reset, branch resurrection, detached HEAD recovery, or force-push mistakes. - Read
references/history-surgery.md for interactive rebase, commit splitting, autosquash, cherry-pick cleanup, and safe force-push guidance. - Read
references/advanced-patterns.md for worktree, bisect, subtree, submodule, sparse checkout, and repository-structure decisions.
Output template
When responding on a git workflow task, prefer this structure:
- - Goal:
- Risk level:
- Safe first check:
- Recommended commands:
- Rollback path:
- Shared-history warning:
Git 工作流
使用此技能处理非简单的Git工作，当安全性、历史清晰度或仓库结构比单个命令更重要时。
保持主线聚焦于用户的目标。优先选择最小安全序列的Git操作。
核心方法
在建议命令之前，确定：
- 1. 用户的目标
- 历史是否已与他人共享
- 任务是否更改提交、引用、工作树或仓库结构
- 是否应首先准备恢复
如果某一步骤具有破坏性或难以撤销，请先创建安全点。
默认安全规则
- - 在编辑历史前检查 git status。
- 在变基、重置或强制推送前检查当前分支和上游。
- 优先进行非破坏性检查。
- 当清晰度重要时，优先使用 git switch 和 git restore 而非旧式混合形式。
- 在进行有风险的历史手术前创建恢复点。
- 除非用户明确希望权衡，否则避免重写共享历史。
- 当涉及冲突或恢复时，同时解释即时修复和回滚路径。
恢复优先操作
当风险较高时，尽早使用这些模式：
bash
git status
git branch backup/$(date +%Y%m%d-%H%M%S)-preop
对于历史恢复，在更改任何内容前进行检查：
bash
git reflog --date=local --decorate -n 30
git log --oneline --graph --decorate -n 30
阅读 references/recovery.md 了解基于reflog的恢复、重置恢复、分支恢复和强制推送错误。
常见任务类别
历史清理
用于：
- - 压缩修复提交
- 修改提交信息
- 拆分不良提交
- 删除意外提交
- 在合并前准备分支
优先对本地或尚未共享的历史使用交互式变基。
Bug起源追踪
当用户知道一个良好状态和一个不良状态，需要找到引入提交时，使用 git bisect。
并行分支工作
当用户需要同时检出两个分支、想要更清晰的修复流程或避免暂存时，使用 git worktree。
冲突处理
在变基、合并、拣选或应用暂存时谨慎解决。保留用户意图，而不仅仅是文件合并成功。
仓库考古
当用户需要回答以下问题时，使用blame、pickaxe、grep、日志图和路径历史：
- - 谁更改了此内容
- 此内容何时损坏
- 此行来自何处
- 哪个提交移除了此行为
仓库结构变更
对以下情况格外小心：
- - 子模块
- 子树
- 稀疏检出
- 工作树修剪
- 分支重命名
- 默认分支迁移
当任务涉及仓库拓扑而非简单的日常提交时，阅读 references/advanced-patterns.md。
决策规则
变基 vs 合并
- - 优先使用变基清理本地功能分支历史。
- 当保留共享分支历史重要时，优先使用合并。
- 如果分支已共享，在变基前明确指出重写风险。
子树 vs 子模块
- - 当用户想要更简单的使用方式和更少的贡献者陷阱时，优先使用子树。
- 当用户真正需要固定的外部仓库边界时，优先使用子模块。
工作树 vs 暂存
- - 对于中长期的并行工作，优先使用工作树。
- 对于短时间中断或小型上下文切换，优先使用暂存。
重置 vs 恢复 vs 还原
- - 对于文件级别的撤销，优先使用 restore。
- 对于本地历史和索引手术，优先使用 reset。
- 对于撤销已共享的提交，优先使用 revert。
操作风格
在指导用户时：
- 1. 说明应首先检查什么状态
- 陈述最安全的命令序列
- 注明历史是否正在被重写
- 当风险较大时给出回滚路径
保持命令集简短。除非必要，不要列出所有Git选项。
何时阅读参考资料
- - 阅读 references/recovery.md 了解reflog恢复、意外重置、分支复活、分离HEAD恢复或强制推送错误。
- 阅读 references/history-surgery.md 了解交互式变基、提交拆分、自动压缩、拣选清理和安全强制推送指南。
- 阅读 references/advanced-patterns.md 了解工作树、二分查找、子树、子模块、稀疏检出和仓库结构决策。
输出模板
在回应Git工作流任务时，优先使用此结构：
- - 目标：
- 风险等级：
- 安全优先检查：
- 推荐命令：
- 回滚路径：
- 共享历史警告：
