
Git Pushing
- 378 installs
- 656 repo stars
- Updated July 25, 2026
- mhattingpete/claude-skills-marketplace
git-pushing is a Claude agent skill that pushes reviewed branches to remotes, sets upstream tracking, and completes handoff from local commits to CI or pull-request review for developers avoiding manual git push mistakes
About
git-pushing is a mhattingpete/claude-skills-marketplace agent skill that safely pushes reviewed local branches to remotes and configures upstream tracking so CI pipelines and pull-request review start without manual git errors. It handles the fragile transition between finished local commits and remote visibility—correct remote names, first-push upstream flags, and branch tracking setup that developers often mistype under deadline pressure. Developers invoke git-pushing after code review passes locally and before opening or updating a pull request that depends on remote branch presence. The skill reduces failed pushes, wrong-remote mistakes, and untracked branches that leave CI idle. Reach for git-pushing when handoff from local worktrees to team review workflows must be reliable and repeatable across contributors who may not memorize git push variants. Outputs are pushed remote branches with upstream configured, ready for GitHub Actions, GitLab CI, or PR creation steps.
- Upstream branch setup
- Safe push workflows
- Remote sync checks
- PR-ready branch hygiene
- Recover from push errors
Git Pushing by the numbers
- 378 all-time installs (skills.sh)
- +7 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #123 of 733 Git & Pull Requests skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/mhattingpete/claude-skills-marketplace --skill git-pushingAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 378 |
|---|---|
| repo stars | ★ 656 |
| Last updated | July 25, 2026 |
| Repository | mhattingpete/claude-skills-marketplace ↗ |
How do you push a branch and set upstream tracking?
Push reviewed branches to remotes, set upstream tracking, and complete the handoff from local commits to CI or pull-request review without manual git mistakes.
Who is it for?
Developers finishing local commits who need reliable git push and upstream setup before CI or pull-request review starts.
Skip if: Developers still writing unreviewed local changes who have not finished commits or branch preparation before remote push.
When should I use this skill?
A developer asks to push a reviewed branch, set upstream tracking, or complete handoff from local commits to CI or pull-request review.
What you get
Remote branch with upstream tracking configured, pushed commits visible to CI, and pull-request pipeline ready for review handoff.
- Pushed remote branch
- Upstream tracking configuration
Files
Git Push Workflow
Stage all changes, create a conventional commit, and push to the remote branch.
When to Use
Automatically activate when the user:
- Explicitly asks to push changes ("push this", "commit and push")
- Mentions saving work to remote ("save to github", "push to remote")
- Completes a feature and wants to share it
- Says phrases like "let's push this up" or "commit these changes"
Workflow
ALWAYS use the script - do NOT use manual git commands:
bash skills/git-pushing/scripts/smart_commit.shWith custom message:
bash skills/git-pushing/scripts/smart_commit.sh "feat: add feature"Script handles: staging, conventional commit message, Claude footer, push with -u flag.
#!/bin/bash
# Smart Git Commit Script for git-pushing skill
# Handles staging, commit message generation, and pushing
set -e # Exit on error
# Colors for output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color
# Function to print colored messages
info() { echo -e "${GREEN}→${NC} $1"; }
warn() { echo -e "${YELLOW}⚠${NC} $1"; }
error() { echo -e "${RED}✗${NC} $1" >&2; }
# Get current branch
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
info "Current branch: $CURRENT_BRANCH"
# Check if there are changes
if git diff --quiet && git diff --cached --quiet; then
warn "No changes to commit"
exit 0
fi
# Stage all changes
info "Staging all changes..."
git add .
# Get staged files for commit message analysis
STAGED_FILES=$(git diff --cached --name-only)
DIFF_STAT=$(git diff --cached --stat)
# Analyze changes to determine commit type
determine_commit_type() {
local files="$1"
# Check for specific patterns
if echo "$files" | grep -q "test"; then
echo "test"
elif echo "$files" | grep -qE "\.(md|txt|rst)$"; then
echo "docs"
elif echo "$files" | grep -qE "package\.json|requirements\.txt|Cargo\.toml"; then
echo "chore"
elif git diff --cached | grep -qE "^[\+].*fix|^[\+].*bug"; then
echo "fix"
elif git diff --cached | grep -qE "^[\+].*refactor"; then
echo "refactor"
else
echo "feat"
fi
}
# Analyze files to determine scope
determine_scope() {
local files="$1"
# Extract directory or component name
local scope=$(echo "$files" | head -1 | cut -d'/' -f1)
# Check for common patterns
if echo "$files" | grep -q "plugin"; then
echo "plugin"
elif echo "$files" | grep -q "skill"; then
echo "skill"
elif echo "$files" | grep -q "agent"; then
echo "agent"
elif [ -n "$scope" ] && [ "$scope" != "." ]; then
echo "$scope"
else
echo ""
fi
}
# Generate commit message if not provided
if [ -z "$1" ]; then
COMMIT_TYPE=$(determine_commit_type "$STAGED_FILES")
SCOPE=$(determine_scope "$STAGED_FILES")
# Count files changed
NUM_FILES=$(echo "$STAGED_FILES" | wc -l | xargs)
# Generate description based on changes
if [ "$COMMIT_TYPE" = "docs" ]; then
DESCRIPTION="update documentation"
elif [ "$COMMIT_TYPE" = "test" ]; then
DESCRIPTION="update tests"
elif [ "$COMMIT_TYPE" = "chore" ]; then
DESCRIPTION="update dependencies"
else
DESCRIPTION="update $NUM_FILES file(s)"
fi
# Build commit message
if [ -n "$SCOPE" ]; then
COMMIT_MSG="${COMMIT_TYPE}(${SCOPE}): ${DESCRIPTION}"
else
COMMIT_MSG="${COMMIT_TYPE}: ${DESCRIPTION}"
fi
info "Generated commit message: $COMMIT_MSG"
else
COMMIT_MSG="$1"
info "Using provided message: $COMMIT_MSG"
fi
# Create commit with Claude Code footer
git commit -m "$(cat <<EOF
${COMMIT_MSG}
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
COMMIT_HASH=$(git rev-parse --short HEAD)
info "Created commit: $COMMIT_HASH"
# Push to remote
info "Pushing to origin/$CURRENT_BRANCH..."
# Check if branch exists on remote
if git ls-remote --exit-code --heads origin "$CURRENT_BRANCH" >/dev/null 2>&1; then
# Branch exists, just push
if git push; then
info "Successfully pushed to origin/$CURRENT_BRANCH"
echo "$DIFF_STAT"
else
error "Push failed"
exit 1
fi
else
# New branch, push with -u
if git push -u origin "$CURRENT_BRANCH"; then
info "Successfully pushed new branch to origin/$CURRENT_BRANCH"
echo "$DIFF_STAT"
# Check if it's GitHub and show PR link
REMOTE_URL=$(git remote get-url origin)
if echo "$REMOTE_URL" | grep -q "github.com"; then
REPO=$(echo "$REMOTE_URL" | sed -E 's/.*github\.com[:/](.*)\.git/\1/')
warn "Create PR: https://github.com/$REPO/pull/new/$CURRENT_BRANCH"
fi
else
error "Push failed"
exit 1
fi
fi
exit 0
Related skills
How it compares
Use git-pushing for post-review remote handoff; use commit-message skills when the task is formatting local commits before push.
FAQ
What does git-pushing handle after local review?
git-pushing pushes reviewed branches to remotes, sets upstream tracking, and completes handoff to CI or pull-request review. The mhattingpete/claude-skills-marketplace skill targets the transition from finished local commits to remote visibility without common push mistakes.
When should developers invoke git-pushing?
Developers should invoke git-pushing after local commits are reviewed and ready for remote visibility, before opening or updating pull requests. The skill configures upstream tracking so CI pipelines and team review workflows start reliably.