remote
Skill2 starsChanged 21 days agoMITView on GitHub
Parent Skill: /git Path: /git/remote Trigger automatically when: - User mentions: remote, fetch, push, pull, origin, upstream, fork, sync - Pushing code to GitHub/GitLab - Syncing with team repository - Managing multiple remotes - Fork synchronization Chat commands: Problem: Connect local repository to remote hosting Remove remote: Multiple remotes: Impact: Proper remote configuration prevents errors When to use: - Cloning repository - Forking projects - Changing remote URLs - Adding team repositories Problem: Understand when to use fetch vs pull
- Reads credentials
- Deletes or force-pushes
- Commits and pushes
2 other projects use a version of this.
Adopted by
Most recently taken up by
- bks-lab/open-bridgetheir own version, first seen Oct 30, 2026
- apideck-libraries/api-skillstheir own version, first seen Aug 13, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- bks-lab/open-bridge★ 13same name
- apideck-libraries/api-skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository39 other files it gives its agents.
- skills/react-best-practices/AGENTS.mdAGENTS.md
- skills/vercel-composition-patterns/AGENTS.mdAGENTS.md
- check-seoSkill
- brainstormingSkill
- check-seoSkill
- code-reviewerSkill
- create-a-skillSkill
- dispatching-parallel-agentsSkill
- executing-plansSkill
- finishing-a-development-branchSkill
- frontend-designSkill
- advancedSkill
- basicsSkill
- branchingSkill
- conflictsSkill
- historySkill
- gitSkill
- undoSkill
- workflowsSkill
- vercel-react-best-practicesSkill
- receiving-code-reviewSkill
- requesting-code-reviewSkill
- senior-backendSkill
- senior-frontendSkill
- senior-fullstackSkill
- senior-qaSkill
- skill-creatorSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- test-fullySkill
- using-git-worktreesSkill
- using-screenkitSkill
- vercel-composition-patternsSkill
- verification-before-completionSkill
- webapp-testingSkill
- web-crawlerSkill
- writing-plansSkill
- writing-skillsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
21 rules. About 0 are common, 19 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈19
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 54
ALWAYS pull before push to avoid conflicts
- Distinctive: line 55
NEVER force push to shared/main branches
- Very specific: line 56
ALWAYS use --force-with-lease instead of --force
- Distinctive: line 57
NEVER commit credentials or secrets before pushing
- Distinctive: line 58
ALWAYS verify remote URL before pushing
- Distinctive: line 59
Use SSH for push access, HTTPS for read-only </critical>
- Distinctive: line 203
Fetch: When you want to review changes first
- Distinctive: line 204
Pull: When you trust the changes (e.g., your own other branch)
- Distinctive: line 267
Problem: Keep local branch in sync with remote
- Distinctive: line 453
After rebasing your feature branch
- Distinctive: line 454
After amending your commits
- Distinctive: line 456
NEVER on shared branches
- Distinctive: line 462
Problem: Keep forked repository up to date
- Distinctive: line 518
Before starting new feature
- Distinctive: line 520
Before creating pull request
- Distinctive: line 714
Pull before push: - Always fetch/pull before pushing
- Distinctive: line 716
Verify remotes: - Check remote URLs are correct
- Distinctive: line 718
Clean up branches: - Delete merged branches
- Very specific: line 719
Force push carefully: - Use --force-with-lease only on your branches
- Distinctive: line 720
Tag releases: - Use tags for version milestones
- Distinctive: line 721
Sync forks regularly: - Keep upstream in sync
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Git Remote
Parent Skill: /git
Path: /git/remote
Purpose
Master remote repository operations including adding remotes, fetching, pulling, pushing, managing multiple remotes (origin/upstream), and syncing forks.
When to Use
Trigger automatically when:
- User mentions: remote, fetch, push, pull, origin, upstream, fork, sync
- Pushing code to GitHub/GitLab
- Syncing with team repository
- Managing multiple remotes
- Fork synchronization
Chat commands:
/git/remote push my branch to GitHub
/git/remote sync my fork with upstream
/git/remote what's the difference between fetch and pull
/git/remote add upstream repository
/git/remote force push safelyRequirements
<critical>
- Git repository with at least one commit
- Remote repository access (GitHub, GitLab, Bitbucket)
- Authentication configured (SSH keys or HTTPS credentials)
- Network connectivity
- Push access for push operations
</critical>Verification
# Check remote configuration
git remote -v
# Test authentication
git ls-remote origin
# Check tracking branches
git branch -vvCritical Rules
<critical>
1. ALWAYS pull before push to avoid conflicts
2. NEVER force push to shared/main branches
3. ALWAYS use --force-with-lease instead of --force
4. NEVER commit credentials or secrets before pushing
5. ALWAYS verify remote URL before pushing
6. Use SSH for push access, HTTPS for read-only
</critical>Remote Workflow
Local Repository ←→ Remote Repository (origin)
↑
└─→ Upstream Repository (for forks)
Commands:
fetch: Download changes (don't merge)
pull: Download and merge (fetch + merge)
push: Upload local commitsPatterns
Pattern 1: Add and Remove Remotes
Problem: Connect local repository to remote hosting
# ❌ BAD: Add remote without verification
git remote add origin https://github.com/user/repo.git
# Typo in URL? Won't know until push fails!
# ✅ GOOD: Add remote and verify
git remote add origin git@github.com:user/repo.git
git remote -v # Verify URL
git ls-remote origin # Test connection
# ✅ BETTER: Add with immediate fetch
git remote add origin git@github.com:user/repo.git
git fetch originRemove remote:
# Remove remote
git remote remove origin
# Or rename
git remote rename origin old-origin
# Update remote URL
git remote set-url origin git@github.com:user/new-repo.gitMultiple remotes:
# Add origin (your fork)
git remote add origin git@github.com:you/repo.git
# Add upstream (original repository)
git remote add upstream git@github.com:original/repo.git
# Verify
git remote -v
# origin git@github.com:you/repo.git (fetch)
# origin git@github.com:you/repo.git (push)
# upstream git@github.com:original/repo.git (fetch)
# upstream git@github.com:original/repo.git (push)Impact: Proper remote configuration prevents errors
When to use:
- Cloning repository
- Forking projects
- Changing remote URLs
- Adding team repositories
Pattern 2: Fetch vs Pull
Problem: Understand when to use fetch vs pull
# ❌ BAD: Pull without knowing what's coming
git pull # Automatically merges! May cause conflicts
# ✅ GOOD: Fetch first, review, then merge
git fetch origin
# See what's new
git log HEAD..origin/main
git diff HEAD..origin/main
# Then decide to merge
git merge origin/main
# Or rebase
git rebase origin/mainFetch workflow:
# Fetch all branches from origin
git fetch origin
# Fetch specific branch
git fetch origin main
# Fetch all remotes
git fetch --all
# Prune deleted branches
git fetch --prune
git fetch -p # Short formPull workflow:
# Pull with merge (default)
git pull origin main
# Pull with rebase (cleaner history)
git pull --rebase origin main
# Pull current branch
git pull # If upstream tracking setConfigure default pull behavior:
# Use merge (creates merge commit)
git config pull.rebase false
# Use rebase (linear history)
git config pull.rebase true
# Fail if can't fast-forward (safest)
git config pull.ff onlyImpact: Control over when and how changes are integrated
When to use:
- Fetch: When you want to review changes first
- Pull: When you trust the changes (e.g., your own other branch)
Pattern 3: Push to Remote
Problem: Upload local commits to remote repository
# ❌ BAD: Push without setting upstream
git push # Error: no upstream branch
# ✅ GOOD: Push and set upstream tracking
git push -u origin feature-branch
# Now 'git push' works without arguments
# ✅ BETTER: Verify before push
git log origin/main..HEAD # See what will be pushed
git diff origin/main..HEAD # Review changes
git push -u origin feature-branchFirst push to new repository:
# After initial commit
git branch -M main # Rename to main
git remote add origin git@github.com:user/repo.git
git push -u origin main
# Now clone other computer and push works with:
git pushPush different branch:
# Push local branch to remote with different name
git push origin local-branch:remote-branch
# Push to different remote
git push upstream feature-branchDelete remote branch:
# Delete remote branch
git push origin --delete feature-branch
# Old syntax (still works)
git push origin :feature-branchImpact: Share work with team and backup code
When to use:
- Sharing feature branch
- Backing up work
- After completing feature
- End of work day
Pattern 4: Track Remote Branches
Problem: Keep local branch in sync with remote
# ❌ BAD: Manual tracking
git branch feature-branch
git push origin feature-branch
# No tracking relationship!
# ✅ GOOD: Push with upstream tracking
git push -u origin feature-branch
# or
git push --set-upstream origin feature-branch
# Now these work:
git pull # Pulls from origin/feature-branch
git push # Pushes to origin/feature-branchCheck tracking status:
# See tracking info
git branch -vv
# * main abc1234 [origin/main] Latest commit
# feature def5678 [origin/feature: ahead 2] Feature work
# Ahead/behind status
git status -sb
# ## main...origin/main [ahead 1, behind 2]Set tracking after creation:
# Branch already exists
git branch --set-upstream-to=origin/main main
# Or
git branch -u origin/main mainCheckout and track remote branch:
# See remote branches
git branch -r
# Checkout remote branch (creates local tracking branch)
git switch feature-from-teammate
# Git automatically creates local branch tracking origin/feature-from-teammate
# Or explicit
git switch -c local-name origin/remote-branchImpact: Simplified push/pull workflow
When to use:
- Creating feature branches
- Collaborating on branches
- Team workflows
Pattern 5: Multiple Remotes (Origin & Upstream)
Problem: Manage fork and upstream repository
# ❌ BAD: Only origin configured
git remote -v
# origin git@github.com:you/repo.git (fetch)
# origin git@github.com:you/repo.git (push)
# Can't sync with upstream!
# ✅ GOOD: Both origin and upstream
# Fork on GitHub, then:
git clone git@github.com:you/repo.git
cd repo
git remote add upstream git@github.com:original/repo.git
git remote -v
# origin git@github.com:you/repo.git (fetch)
# origin git@github.com:you/repo.git (push)
# upstream git@github.com:original/repo.git (fetch)
# upstream git@github.com:original/repo.git (push)Workflow with fork:
# Sync with upstream
git fetch upstream
git checkout main
git merge upstream/main # or rebase
git push origin main
# Create feature from upstream
git fetch upstream
git checkout -b feature-x upstream/main
# Work on feature
git add .
git commit -m "feat: add feature"
# Push to your fork
git push -u origin feature-x
# Create PR from your fork to upstreamConfigure push/fetch separately:
# Fetch from upstream, push to origin
git config remote.upstream.pushurl "DISABLE"
# Or set different URLs
git remote set-url --push upstream DISABLEImpact: Proper fork workflow for open source
When to use:
- Contributing to open source
- Working with forked repositories
- Team members with forks
Pattern 6: Force Push Safely
Problem: Need to force push after rebase/amend
# ❌ DANGEROUS: Force push
git push --force
# Can overwrite teammate's work!
# ✅ GOOD: Force with lease
git push --force-with-lease
# Fails if remote branch changed since last fetch
# ✅ BETTER: Force with lease on specific branch
git push --force-with-lease origin feature-branchWhen force push is OK:
# After interactive rebase on YOUR branch
git rebase -i HEAD~3
git push --force-with-lease origin feature-branch
# After amending last commit
git commit --amend
git push --force-with-lease
# After fixing commits in PR
git rebase -i upstream/main
git push --force-with-lease origin pr-branchWhen force push is NOT OK:
# ❌ NEVER force push to:
# - main or master branch
# - develop or release branches
# - Any branch others are using
# - Public branches
# If you must (emergency):
# 1. Communicate with team first!
# 2. Make sure everyone has pushed their work
# 3. Use --force-with-lease
# 4. Tell team to reset: git fetch && git reset --hard origin/mainSafer alternatives:
# Instead of force push, use revert
git revert HEAD
git push
# Or create new branch
git switch -c fixed-feature-branch
git push -u origin fixed-feature-branchImpact: Prevent data loss from overwrites
When to use:
- After rebasing your feature branch
- After amending your commits
- Cleaning up PR before merge
- NEVER on shared branches
Pattern 7: Sync Fork with Upstream
Problem: Keep forked repository up to date
# ❌ BAD: Manually download and push
# Download zip from upstream
# Extract and copy files
# Commit and push
# This loses Git history!
# ✅ GOOD: Proper sync workflow
# One-time setup
git remote add upstream git@github.com:original/repo.git
# Sync workflow (do regularly)
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
# ✅ BETTER: Sync with rebase (cleaner)
git fetch upstream
git checkout main
git rebase upstream/main
git push --force-with-lease origin main
# Only if no one else uses your fork's main!Sync feature branch:
# Update your feature with upstream changes
git fetch upstream
git checkout feature-branch
git rebase upstream/main
git push --force-with-lease origin feature-branchGitHub web UI sync:
# Can also use "Sync fork" button on GitHub
# Then locally:
git checkout main
git pull origin mainAutomated sync:
# Create alias
git config alias.sync-fork '!git fetch upstream && git checkout main && git merge upstream/main && git push origin main'
# Use:
git sync-forkImpact: Stay current with upstream project
When to use:
- Before starting new feature
- Regularly (weekly/monthly)
- Before creating pull request
- Resolving merge conflicts
Pattern 8: Remote Branch Management
Problem: Manage remote branches efficiently
# ❌ BAD: Let remote branches accumulate
git branch -r
# origin/feature-1
# origin/feature-2
# ... 50 old branches ...
# ✅ GOOD: Regular cleanup
# See merged branches
git branch -r --merged main
# Delete remote branches (after PR merged)
git push origin --delete feature-1
git push origin --delete feature-2
# Prune local references to deleted remote branches
git fetch --prune
# or
git remote prune originBulk operations:
# List all remote branches
git ls-remote --heads origin
# Delete multiple remote branches
git push origin --delete branch1 branch2 branch3
# Prune and show what was removed
git fetch --prune --verboseProtected branches:
# Some branches can't be deleted (GitHub/GitLab settings)
# main, develop usually protected
# Check branch protection (GitHub CLI)
gh api repos/:owner/:repo/branches/main/protectionMirror repository:
# Clone with all branches
git clone --mirror git@github.com:user/repo.git
# Push to different remote
cd repo.git
git push --mirror git@gitlab.com:user/repo.gitImpact: Clean, organized remote repository
When to use:
- After PRs merged
- Regular maintenance
- Repository cleanup
- Migrating repositories
Common Workflows
Daily Team Collaboration
# Start of day
git fetch origin
git checkout main
git pull origin main
# Create feature branch
git checkout -b feature-new
# ... work ...
git push -u origin feature-new
# Later: Sync with main
git fetch origin
git rebase origin/main
git push --force-with-lease origin feature-new
# After PR merged
git checkout main
git pull origin main
git branch -d feature-new
git push origin --delete feature-newOpen Source Contribution
# One-time setup
git clone git@github.com:you/forked-repo.git
cd forked-repo
git remote add upstream git@github.com:original/repo.git
# Before starting work
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
# Create feature
git checkout -b feature-contribution
# ... work ...
git push -u origin feature-contribution
# Create PR on GitHub from your forkDeploy to Production
# Ensure main is up to date
git checkout main
git pull origin main
# Tag release
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0
# Push to production remote
git push production mainTroubleshooting
Push rejected (non-fast-forward)
# Error: Updates were rejected
# Option 1: Pull and merge
git pull origin main
git push origin main
# Option 2: Pull with rebase
git pull --rebase origin main
git push origin main
# Option 3: Check if you should force push
git push --force-with-lease origin feature-branchAuthentication failed
# HTTPS credentials
git config credential.helper store
git pull # Will prompt for password once
# SSH key issues
ssh -T git@github.com # Test SSH
ssh-add ~/.ssh/id_ed25519 # Add key to agent
# Switch from HTTPS to SSH
git remote set-url origin git@github.com:user/repo.gitWrong remote URL
# Check current URL
git remote -v
# Update URL
git remote set-url origin git@github.com:correct-user/repo.git
# Verify
git remote -v
git ls-remote originLost tracking branch
# Re-establish tracking
git branch --set-upstream-to=origin/main main
# Or delete and recreate
git branch -d feature
git fetch origin
git checkout feature # Auto-tracks origin/featureBest Practices
- Pull before push - Always fetch/pull before pushing
- Use SSH for push - More secure than HTTPS
- Verify remotes - Check remote URLs are correct
- Fetch regularly - Stay aware of team changes
- Clean up branches - Delete merged branches
- Force push carefully - Use --force-with-lease only on your branches
- Tag releases - Use tags for version milestones
- Sync forks regularly - Keep upstream in sync
Related Sub-Skills
- Need to handle push conflicts? →
/git/conflicts - Need to undo pushed commits? →
/git/undo - Setting up team workflow? →
/git/workflows - Managing branches? →
/git/branching
Quick Command Reference
# Remotes
git remote add origin <url> # Add remote
git remote -v # List remotes
git remote remove origin # Remove remote
# Fetch/Pull
git fetch origin # Download changes
git pull origin main # Fetch and merge
git pull --rebase # Pull with rebase
# Push
git push -u origin branch # Push with tracking
git push --force-with-lease # Safe force push
git push origin --delete branch # Delete remote branch
# Tracking
git branch -vv # Show tracking
git branch -u origin/main # Set upstream
# Multiple remotes
git remote add upstream <url> # Add upstream
git fetch upstream # Fetch from upstream
git merge upstream/main # Merge upstream
# Cleanup
git fetch --prune # Remove stale references
git remote prune origin # Prune remoteLast Updated: 2025-02-11 Version: 1.0.0
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

