git-workflow
Original:🇺🇸 English
Translated
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.
5installs
Sourcejezweb/claude-skills
Added on
NPX Install
npx skill4agent add jezweb/claude-skills git-workflowTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →Git Workflow
Guided workflows for common git operations that benefit from structured steps.
PR Preparation
When preparing a pull request:
-
Gather context
- — list all commits on the branch
git log main..HEAD --oneline - — see all changed files
git diff main...HEAD --stat - — check for uncommitted work
git status
-
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 createbash
git push -u origin HEAD gh pr create --title "..." --body "$(cat <<'EOF' ## Summary - ... ## Test plan - [ ] ... 🤖 Generated with [Claude Code](https://claude.com/claude-code) EOF )" -
Verify —to open in browser
gh pr view --web
Branch Cleanup
Clean up merged branches safely:
-
Switch to main and pull latestbash
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 branchesbash
git branch --merged main | grep -vE '^\*|main|master|develop' | xargs -r git branch -d -
Prune remote tracking refsbash
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 scopebash
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: or
git rebase --abortgit 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
- Abort:
-
Verify — run tests, check the diff looks right
Monorepo Release Tags
In monorepos, scope tags to the package:
bash
# ❌ Ambiguous in monorepos
git tag v2.1.0
# ✅ Scoped to package
git tag contextbricks-v2.1.0
git push origin contextbricks-v2.1.0Pattern:
{package-name}-v{semver}.gitignore-First Init
When creating a new repo, always create BEFORE the first :
.gitignoregit addbash
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:
bash
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:
bash
gh repo view --json visibility -q '.visibility'If , ensure:
PRIVATE- contains proprietary notice (not MIT/Apache)
LICENSE - has
package.jsonand"license": "UNLICENSED""private": true - No or "contributions welcome" in README
CONTRIBUTING.md