git-workflow
Guided git workflows: prepare PRs, clean up branches, resolve merge conflicts, handle monorepo tags, squash-and-merge patterns. Use when asked to prepare a PR, clean branches, resolve conflicts, or tag a release.
适合你,如果经常需要准备 PR、清理分支或解决合并冲突
/ 下载安装
用别的 agent?下载 .zip 解压,把文件夹放进它的技能目录
Claude Code
~/.claude/skills/(项目级 .claude/skills/)Codex CLI
~/.codex/skills/Cursor自动读取上面两处目录
其他工具见其文档的「skills」目录;两个下载是同一份文件,只是名字不同
/ 通过 npx 安装 校验哈希
npx oh-my-skill add jezweb/claude-skills/git-workflow/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- jezweb/claude-skills/git-workflow/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify jezweb/claude-skills/git-workflow安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
910GitHub stars
~864上下文体积 · 单文件
镜像托管
怎么用
技能原文 SKILL.md
Git Workflow
Guided workflows for common git operations that benefit from structured steps.
PR Preparation
When preparing a pull request:
- Gather context
git log main..HEAD --oneline— list all commits on the branchgit diff main...HEAD --stat— see all changed filesgit status— check for uncommitted work
- Draft PR content
- Title: under 70 chars, describes the change (not the branch name)
- Body: summarise the "why", list key changes, add test plan
- Use the commit history to write the summary — don't rely on memory
- Push and create ```bash git push -u origin HEAD gh pr create --title "..." --body "$(cat <<'EOF' ## Summary
- ...
## Test plan
- [ ] ...
🤖 Generated with Claude Code EOF )" ```
- Verify —
gh pr view --webto open in browser
Branch Cleanup
Clean up merged branches safely:
- Switch to main and pull latest ```bash git checkout main && git pull ```
- List merged branches (excludes main/master/develop) ```bash git branch --merged main | grep -vE '^\*|main|master|develop' ```
- Delete local merged branches ```bash git branch --merged main | grep -vE '^\*|main|master|develop' | xargs -r git branch -d ```
- Prune remote tracking refs ```bash git fetch --prune ```
- List remote branches with no local tracking (optional) ```bash git branch -r --merged origin/main | grep -vE 'main|master|develop|HEAD' ```
Merge Conflict Resolution
When a PR has conflicts:
- Assess the conflict scope ```bash git fetch origin git merge origin/main --no-commit --no-ff git diff --name-only --diff-filter=U # List conflicted files ```
- For each conflicted file, read the file and resolve:
- Keep both changes if they're in different areas
- If architecturally incompatible, prefer the main branch's approach and re-apply the PR's intent on top
- If rebase is cleaner (few commits, no shared history): ```bash git rebase origin/main # Resolve conflicts per commit, then: git rebase --continue ```
- If rebase is messy (many conflicts, architectural divergence):
- Abort:
git rebase --abortorgit merge --abort - Extract useful code:
git show origin/branch:path/to/file > /tmp/extracted.txt - Apply changes manually to main
- Close original PR with explanation
- Verify — run tests, check the diff looks right
Monorepo Release Tags
In monorepos, scope tags to the package:
# ❌ Ambiguous in monorepos git tag v2.1.0 # ✅ Scoped to package git tag contextbricks-v2.1.0 git push origin contextbricks-v2.1.0
Pattern: {package-name}-v{semver}
.gitignore-First Init
When creating a new repo, always create .gitignore BEFORE the first git add:
cat > .gitignore << 'EOF' node_modules/ .wrangler/ dist/ .dev.vars *.log .DS_Store .env .env.local EOF git init && git add . && git commit -m "Initial commit"
If node_modules is already tracked:
git rm -r --cached node_modules/ git commit -m "Remove node_modules from tracking"
Private Repo License Audit
Before publishing or sharing a private repo:
gh repo view --json visibility -q '.visibility'
If PRIVATE, ensure:
LICENSEcontains proprietary notice (not MIT/Apache)package.jsonhas"license": "UNLICENSED"and"private": true- No
CONTRIBUTING.mdor "contributions welcome" in README
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →
评论
登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。
…