Git Workflow

VerifiedCaution

Git operations and pull request workflows. Create PRs, rebase branches, resolve conflicts, merge with rebase. Use when ready to create a PR or when working with git branches and upstream.

Sby Skills Guide Bot
DevelopmentIntermediate
806/2/2026
Claude Code
#git#pull-requests#rebase#workflow#collaboration

Recommended for

Our review

Handles advanced Git operations such as creating pull requests, rebasing branches, and resolving conflicts to contribute to upstream repositories.

Strengths

  • Automates updating and rebasing before PR creation
  • Supports both forks and direct branch workflows on the main repo
  • Includes conflict resolution steps with clear instructions

Limitations

  • Requires the user to have configured upstream and origin remotes
  • Complex rebase conflicts may still require manual intervention
  • Assumes changes are already committed locally
When to use it

When you need to create a pull request to an upstream repository after working on a branch or fork.

When not to use it

For simple commits directly to main on a personal repository where no PR workflow is needed.

Security analysis

Caution
Quality score88/100

The skill describes a standard git collaboration workflow including branching, rebasing, pushing, and creating pull requests. While the commands themselves are not destructive or obfuscated, they involve network operations (git push, fetch) that could potentially expose data if the remote is malicious, and force push with lease can overwrite remote branches. The skill includes a guardrail to wait for user confirmation before pushing or creating PRs, reducing risk.

Findings
  • Uses git push with --force-with-lease, which can overwrite remote history if misapplied.
  • Instructs reading configuration from a local file (.claude-workspace), but no exfiltration risk.

Examples

Create a PR from a fork
Create a pull request from my fork to the upstream repository for the pattern I just committed.
Rebase feature branch before PR
Update my current branch with the latest changes from upstream main and rebase before creating a pull request.

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:

  1. Show conflict files: git status
  2. Help resolve conflicts
  3. Continue: git rebase --continue
  4. 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 --squash or --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
Related skills