| name | git-workflow |
| description | Git operations and pull request workflows. Create PRs, rebase branches, resolve conflicts, merge to upstream. Use when ready to create PR or when working with git branches and upstream. |
Git Workflow
Committing Work
cd ~/Code/community-patterns
git add patterns/$GITHUB_USER/pattern.tsx
git commit -m "Add pattern: description"
git push origin main
Getting Updates (Already done in Step 1)
git fetch upstream
git pull --rebase upstream main
git push origin main
Sharing Work Upstream (Creating Pull Requests)
IMPORTANT: Wait for user to tell you to create a PR. Don't push or create PRs automatically.
Before creating any PR, you MUST update from main and rebase your branch:
Step 0: Update and Rebase Before Creating PR
Use cached repository type from workspace config:
# Read IS_FORK from .claude-workspace (set during Step 2)
IS_FORK=$(grep "^is_fork=" .claude-workspace | cut -d= -f2)
# Determine which remote to use
if [ "$IS_FORK" = "true" ]; then
echo "Working on fork - will fetch from upstream"
MAIN_REMOTE="upstream"
else
echo "Working on main repo - will fetch from origin"
MAIN_REMOTE="origin"
fi
Then fetch latest main and rebase your branch:
# Fetch latest main
git fetch $MAIN_REMOTE
# Rebase current branch on top of main
git rebase $MAIN_REMOTE/main
# If rebase succeeds, push (force-with-lease if on feature branch)
if [ "$(git branch --show-current)" != "main" ]; then
git push origin $(git branch --show-current) --force-with-lease
else
git push origin main
fi
If rebase has conflicts:
- Show conflict files:
git status - Help resolve conflicts
- Continue:
git rebase --continue - Then push
Why this matters:
- Ensures your PR is based on the latest main
- Avoids merge conflicts during PR review
- Makes PR review easier
If User Has Their Own Fork (Most Common)
When user wants to contribute patterns from their fork to upstream:
Step 1: Ensure changes are committed and pushed to their fork
cd ~/Code/community-patterns
git status # Verify all changes are committed
git push origin main
Step 2: Update and rebase (see Step 0 above)
Step 3: Create pull request to upstream
gh pr create \
--repo jkomoros/community-patterns \
--title "Add: pattern name" \
--body "$(cat <<'EOF'
## Summary
- Brief description of the pattern
- Key features
- Use cases
## Testing
- [x] Pattern compiles without errors
- [x] Tested in browser at http://localhost:8000
- [x] All features working as expected
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
If Working Directly on jkomoros/community-patterns
CRITICAL: When working directly on the upstream repository, you MUST use branches and PRs. Direct pushes to main are NOT allowed.
Step 1: Create feature branch
cd ~/Code/community-patterns
git checkout -b username/feature-name
Step 2: Commit and push branch
git add patterns/$GITHUB_USER/
git commit -m "Add: pattern name"
git push origin username/feature-name
Step 3: Update and rebase (see Step 0 above)
Step 4: Create pull request
gh pr create \
--title "Add: pattern name" \
--body "$(cat <<'EOF'
## Summary
- Brief description
## Testing
- [x] Tested and working
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
Step 5: Merge with rebase (when approved)
gh pr merge PR_NUMBER --rebase --delete-branch
Important Notes
- Always wait for user permission before creating PRs
- All PRs are merged with
--rebase(NOT--squashor--merge) - This preserves individual commit history
- Commit frequently locally, but only create PR when user asks
- PRs will be reviewed before merging to upstream
- After merge, everyone gets your patterns automatically on next update