Should I always rebase onto main before pushing?

Rebasing onto origin/main is optional but recommended for a linear history and to minimize merge commits.

What should I do if push is rejected due to remote updates?

Rebase and then push again, e.g., git pull --rebase && git push.

When is force-pushing appropriate?

Only after explicit user consent; use git push --force-with-lease to avoid overwriting others' work.

git-push

npx machina-cli add skill gologo13/agent-skills/git-push --openclaw

Files (1)

SKILL.md

881 B

Git Push (sync with origin)

Overview

Push current branch to origin and sync with remote updates.

Steps

Fetch and rebase onto latest main (optional but recommended)
- git fetch origin
- git rebase origin/main || git rebase --abort (if not on main, rebase your feature branch onto latest main)
Push current branch
- git push -u origin HEAD
If push rejected due to remote updates
- Rebase and push: git pull --rebase && git push

Notes

Prefer rebase over merge for a linear history.
If you need to force push after a rebase: you need to ask the user if they want to force push: git push --force-with-lease.

Source

git clone https://github.com/gologo13/agent-skills/blob/main/skills/git-push/SKILL.mdView on GitHub

Overview

Pushes your current branch to origin and keeps it in sync with remote updates. Optional rebasing onto origin/main helps maintain a linear history and reduce merge noise. If the remote has updates, the workflow can rebase and retry the push to resolve conflicts gracefully.

How This Skill Works

The workflow fetches origin, optionally rebases your feature branch onto origin/main, and then pushes the branch with upstream tracking. If the push is rejected due to remote updates, it rebases again and retries the push to align with the latest remote state.

When to Use It

You want to push your current feature branch to origin and start tracking it.
You plan to incorporate the latest changes from origin/main before pushing your branch.
Your push is rejected because the remote has new commits; you need to rebase and push again.
You prefer a linear history and want to minimize merge commits by using rebase.
You're preparing to open a PR and want to ensure your branch is in sync with the remote before submission.

Quick Start

Step 1: git fetch origin; git rebase origin/main (optional, if not on main)
Step 2: git push -u origin HEAD
Step 3: If rejected, git pull --rebase && git push

Best Practices

Review diffs and the impact scope before executing the push.
Fetch origin and rebase onto origin/main before pushing to keep history clean.
Push with upstream tracking: git push -u origin HEAD.
If push is rejected, rebase and retry: git pull --rebase && git push.
Only perform a forced push after explicit user consent: git push --force-with-lease.

Example Use Cases

A feature branch 'feature/search' rebases onto origin/main and pushes with upstream.
Remote has new commits; you rebase your branch and push again to update the PR.
You rebased your branch and decide to force-push with lease after user confirmation.
Before opening a PR from a fork, you fetch and rebase to include the latest main.
During a rebase, conflicts are resolved locally and then the branch is pushed.

Frequently Asked Questions

Add this skill to your agents