When to Use
Use when the task involves Git repositories, branches, commits, merges, rebases, pull requests, conflict resolution, history inspection, or recovery. This skill is stateless and should be applied by default whenever Git work is part of the job.
Quick Reference
| Topic | File |
|---|
| Essential commands | INLINECODE0 |
| Advanced operations |
advanced.md |
| Branch strategies |
branching.md |
| Conflict resolution |
conflicts.md |
| History and recovery |
history.md |
| Team workflows |
collaboration.md |
Core Rules
- 1. Never force push to shared branches — Use
--force-with-lease on feature branches only - Commit early, commit often — Small commits are easier to review, revert, and bisect
- Write meaningful commit messages — First line under 72 chars, imperative mood
- Pull before push — Always
git pull --rebase before pushing to avoid merge commits - Clean up before merging — Use
git rebase -i to squash fixup commits
Team Workflows
Feature Branch Flow:
- 1.
git checkout -b feature/name from main - Make commits, push regularly
- Open PR, get review
- Squash and merge to main
- Delete feature branch
Hotfix Flow:
- 1.
git checkout -b hotfix/issue from main - Fix, test, commit
- Merge to main AND develop (if exists)
- Tag the release
Daily Sync:
CODEBLOCK0
Commit Messages
- - Use conventional commit format: INLINECODE11
- Keep first line under 72 characters
- Types:
feat, fix, docs, style, refactor, test, INLINECODE18
Push Safety
- - Use
git push --force-with-lease instead of --force — prevents overwriting others' work - If push rejected, run
git pull --rebase before retrying - Never force push to main/master branch
Conflict Resolution
- - After editing conflicted files, verify no markers remain: INLINECODE22
- Test that code builds before completing merge
- If merge becomes complex, abort with
git merge --abort and try git rebase instead
Branch Hygiene
- - Delete merged branches locally: INLINECODE25
- Clean remote tracking: INLINECODE26
- Before creating PR, rebase feature branch onto latest main
- Use
git rebase -i to squash messy commits before pushing
Safety Checklist
Before destructive operations (reset --hard, rebase, force push):
- - [ ] Is this a shared branch? → Don't rewrite history
- [ ] Do I have uncommitted changes? → Stash or commit first
- [ ] Am I on the right branch? →
git branch to verify - [ ] Is remote up to date? →
git fetch first
Common Traps
- - git user.email wrong — Verify with
git config user.email before important commits - Empty directories — Git doesn't track them, add INLINECODE34
- Submodules — Always clone with INLINECODE35
- Detached HEAD — Use
git switch - to return to previous branch - Push rejected — Usually needs
git pull --rebase first - stash pop on conflict — Stash disappears. Use
stash apply instead - Large files — Use Git LFS for files >50MB, never commit secrets
- Case sensitivity — Mac/Windows ignore case, Linux doesn't — causes CI failures
Recovery Commands
- - Undo last commit keeping changes: INLINECODE39
- Discard unstaged changes: INLINECODE40
- Find lost commits:
git reflog (keeps ~90 days of history) - Recover deleted branch: INLINECODE42
- Use
git add -p for partial staging when commit mixes multiple changes
Debugging with Bisect
Find the commit that introduced a bug:
CODEBLOCK1
Quick Summary
CODEBLOCK2
Related Skills
Install with
clawhub install <slug> if user confirms:
- -
gitlab — GitLab CI/CD and merge requests - INLINECODE46 — Containerization workflows
- INLINECODE47 — Code quality and best practices
Feedback
- - If useful: INLINECODE48
- Stay updated: INLINECODE49
何时使用
当任务涉及 Git 仓库、分支、提交、合并、变基、拉取请求、冲突解决、历史检查或恢复时使用。此技能为无状态技能，只要工作涉及 Git 操作，默认应使用本技能。
快速参考
advanced.md |
| 分支策略 | branching.md |
| 冲突解决 | conflicts.md |
| 历史与恢复 | history.md |
| 团队工作流 | collaboration.md |
核心规则
- 1. 切勿强制推送到共享分支 — 仅在功能分支上使用 --force-with-lease
- 尽早提交，频繁提交 — 小提交更易于审查、回退和二分查找
- 编写有意义的提交信息 — 第一行不超过72个字符，使用祈使语气
- 推送前先拉取 — 推送前始终执行 git pull --rebase，避免产生合并提交
- 合并前清理 — 使用 git rebase -i 压缩修复提交
团队工作流
功能分支流程：
- 1. 从主分支创建：git checkout -b feature/name
- 进行提交，定期推送
- 发起PR，获取审查
- 压缩合并到主分支
- 删除功能分支
热修复流程：
- 1. 从主分支创建：git checkout -b hotfix/issue
- 修复、测试、提交
- 合并到主分支 AND 开发分支（如存在）
- 标记发布版本
每日同步：
bash
git fetch --all --prune
git rebase origin/main # 或根据团队偏好使用合并
提交信息
- - 使用常规提交格式：type(scope): description
- 第一行不超过72个字符
- 类型：feat、fix、docs、style、refactor、test、chore
推送安全
- - 使用 git push --force-with-lease 替代 --force — 防止覆盖他人工作
- 若推送被拒绝，先执行 git pull --rebase 再重试
- 切勿强制推送到 main/master 分支
冲突解决
- - 编辑冲突文件后，确认无残留标记：grep -r <<<\|>>>\|=== .
- 完成合并前测试代码能否构建
- 若合并变得复杂，使用 git merge --abort 中止，尝试改用 git rebase
分支卫生
- - 本地删除已合并分支：git branch -d branch-name
- 清理远程跟踪：git fetch --prune
- 创建PR前，将功能分支变基到最新主分支
- 推送前使用 git rebase -i 压缩杂乱的提交
安全检查清单
执行破坏性操作前（reset --hard、rebase、force push）：
- - [ ] 这是共享分支吗？→ 不要重写历史
- [ ] 我有未提交的更改吗？→ 先暂存或提交
- [ ] 我在正确的分支上吗？→ 用 git branch 确认
- [ ] 远程仓库是最新的吗？→ 先执行 git fetch
常见陷阱
- - git user.email 错误 — 重要提交前用 git config user.email 确认
- 空目录 — Git 不跟踪它们，添加 .gitkeep
- 子模块 — 始终使用 --recurse-submodules 克隆
- 分离头指针 — 使用 git switch - 返回之前分支
- 推送被拒绝 — 通常需要先执行 git pull --rebase
- stash pop 冲突 — 暂存内容消失。改用 stash apply
- 大文件 — 超过50MB的文件使用 Git LFS，切勿提交密钥
- 大小写敏感 — Mac/Windows 忽略大小写，Linux 不忽略 — 导致 CI 失败
恢复命令
- - 撤销上次提交但保留更改：git reset --soft HEAD~1
- 丢弃未暂存的更改：git restore filename
- 查找丢失的提交：git reflog（保留约90天历史）
- 恢复已删除分支：git checkout -b branch-name <来自reflog的sha>
- 提交混合了多个更改时，使用 git add -p 进行部分暂存
使用二分查找调试
找到引入错误的提交：
bash
git bisect start
git bisect bad # 当前提交有问题
git bisect good v1.0.0 # 此版本正常
Git 检出中间提交，测试它，然后：
git bisect good # 或 git bisect bad
重复直到 Git 找到罪魁祸首
git bisect reset # 返回原始分支
快速总结
bash
git status -sb # 带分支的简短状态
git log --oneline -5 # 最近5次提交
git shortlog -sn # 按提交次数排序的贡献者
git diff --stat HEAD~5 # 最近5次提交的更改摘要
git branch -vv # 带跟踪信息的分支
git stash list # 待处理的暂存
相关技能
如果用户确认，使用 clawhub install 安装：
- - gitlab — GitLab CI/CD 和合并请求
- docker — 容器化工作流
- code — 代码质量和最佳实践
反馈
- - 如果觉得有用：clawhub star git
- 保持更新：clawhub sync
