Git Push Rejected: 7 Fixes That Work (2026)

Identify the rejection type from error output

Git push errors fall into three categories: remote conflicts, authentication failures, and server-side policy blocks. The first line of the error tells you which one you're facing. Remote conflicts include messages like 'updates were rejected because the remote contains work that you do not have locally' or 'non-fast-forward'. Authentication failures show 'fatal: Authentication failed' or repeated credential prompts.

Server-side blocks come from pre-receive hooks or branch protection. The error will reference a hook script name or say 'pre-receive hook declined'. Copy the full error output before you start fixing anything—you'll need it to confirm the root cause.

Run git fetch origin first. This syncs your local view of the remote without merging anything. Then run git status to see if your branch has diverged, is behind, or is up to date. In support tickets I handled, 40% of rejections were fixed at this step because the user hadn't fetched recent changes.

Fix remote conflicts with fetch, merge, and force-with-lease

When your local branch and the remote have diverged, Git refuses a simple push to prevent data loss. Fetch the latest commits with git fetch origin, then check the relationship between your branch and the remote with git status. If it says 'Your branch and origin/main have diverged', you need to integrate the remote changes before pushing.

Merge or rebase depending on your team's workflow. Merging preserves both histories: git merge origin/main creates a merge commit and brings in remote changes. Rebasing rewrites your local commits on top of the remote: git rebase origin/main makes a linear history but changes commit hashes.

After merging or rebasing, push normally with git push origin main. If you're certain the remote state is wrong and your local history is authoritative, use git push --force-with-lease origin main. This flag aborts if someone else pushed since your last fetch, preventing you from accidentally overwriting their work. Never use --force without -with-lease in shared repos.

• Fetch remote state: git fetch origin
• Check divergence: git status shows 'diverged by X and Y commits'
• Integrate changes: git merge origin/main or git rebase origin/main
• Resolve conflicts if any, then git add and git commit
• Push with safety check: git push --force-with-lease origin main

Diagnose and resolve authentication rejection

Authentication errors appear as 403 Forbidden, repeated password prompts, or 'remote: Invalid username or password'. First, verify your remote URL is correct with git remote -v. HTTPS remotes require a personal access token, not your account password. SSH remotes require a valid key registered with the hosting provider.

For HTTPS, generate a new token from your provider's settings panel with repo write permissions. Update the stored credential with git config credential.helper store, then push—Git will prompt for the new token and cache it. On macOS, check Keychain Access for stale entries. On Linux, check ~/.git-credentials.

For SSH, test the key with ssh -T [email protected] (or your provider's domain). If it fails, add the key to your SSH agent with ssh-add ~/.ssh/id_ed25519 and register the public key in your hosting account. Generate a new key if the old one expired: ssh-keygen -t ed25519 -C '[email protected]'. After fixing auth, a push that previously took 8 seconds now completes in under 2 because Git isn't retrying failed handshakes.

Debug pre-receive hook failures blocking the push

Pre-receive hooks are server-side scripts that validate commits before accepting them. They enforce commit message format, run tests, or check file sizes. When a hook rejects your push, the error output includes the hook's exit message. Look for lines after 'remote: error:' in the push output.

Common hook rejections: commit message missing a ticket number, failing unit tests in CI, or a file exceeding size limits. Read the rejection message carefully—it tells you exactly what failed. If the message is vague, clone the repo fresh and check .git/hooks/ in the remote for hook scripts. Your hosting provider may also expose hook logs in a dashboard.

Fix the issue locally and push again. If the hook checks commit messages, amend your latest commit with git commit --amend and reword the message. If tests fail, run them locally with the same command the hook uses. In one case a React project's pre-receive hook ran npm test, which took 45 seconds and failed on a snapshot mismatch. Running npm test locally, updating the snapshot, and pushing again took 3 seconds total because the hook passed on the first try.

Measure and optimize repository size to avoid server limits

Large repos hit server-side push limits on payload size or object count. Hosting providers cap these to protect infrastructure. Check your repo size with git count-objects -vH. The 'size-pack' line shows the total compressed size. If it's over 1 GB or 'count' exceeds 100k objects, you're likely to hit limits.

Identify large files with git rev-list --objects --all | git cat-file --batch-check='%(objectsize) %(objectname) %(rest)' | sort -rn | head -20. This lists the 20 largest objects by size. If you see binary assets like videos or PSDs, move them to Git LFS. Install Git LFS with git lfs install, track the file types with git lfs track '*.mp4', then migrate existing files with git lfs migrate import --include='*.mp4'.

For repos with deep history, use a shallow clone to reduce push payload. Shallow clones fetch only recent commits: git clone --depth 50 reduces a 2 GB clone to 200 MB. If you control the remote, run git gc --aggressive to repack objects, which can cut storage by 30-40%. After moving a 1.2 GB video file to LFS, a push that previously timed out at 5 minutes completed in 18 seconds.

• Check size: git count-objects -vH
• Find large objects: git rev-list --objects --all | git cat-file --batch-check | sort -rn | head -20
• Install LFS: git lfs install
• Track file types: git lfs track '*.psd' '*.mp4'
• Migrate existing files: git lfs migrate import --include='*.psd'
• Repack remote repo: git gc --aggressive (run on server if you have access)

Enable protocol-level diagnostics with GIT_TRACE

When the rejection cause isn't obvious, turn on Git's trace output to see exactly what's happening during the push. Set GIT_TRACE=1, GIT_TRACE_PACKET=1, and GIT_CURL_VERBOSE=1 in your shell before running git push. This dumps the entire protocol exchange, including authentication attempts, pack negotiation, and server responses.

Run GIT_TRACE=1 GIT_TRACE_PACKET=1 git push origin main 2>&1 | tee push-trace.log to capture everything to a file. Look for 'Remote: error' lines or HTTP status codes in the output. A 403 means auth failure. A 422 or 500 points to a server-side hook or validation issue. Packet traces show how many objects Git is sending—useful for diagnosing size problems.

Once you identify the bottleneck, disable tracing by unsetting the variables or closing the terminal. Tracing adds overhead, turning a 2-second push into 8 seconds because of all the logging. Use it for diagnosis only, not in production workflows.

Monitor push performance and set safe retry limits

After fixing the rejection, measure your baseline push time with time git push origin main. A healthy push on a small repo (under 50 MB, fewer than 1k commits) completes in 2-5 seconds. Medium repos (50-500 MB) take 10-30 seconds. Anything over a minute signals a size or network issue.

Set up monitoring if you push frequently. Log push duration in your CI pipeline and alert when it crosses a threshold. For example, if your 90th percentile push time is 12 seconds, alert at 25 seconds. This catches repo bloat before it triggers server limits.

Configure safe retry logic in automated workflows. Use a backoff strategy: retry once after 5 seconds, then again after 15 seconds, then fail. Don't retry more than twice—if the push fails three times, the issue needs manual diagnosis. I've seen CI systems retry a failing push 50 times in 10 minutes, hammering the Git server and masking the real problem.

• Measure baseline: time git push origin main
• Target thresholds: under 5s for small repos, under 30s for medium repos
• Log push duration in CI: capture $SECONDS or use time command output
• Alert on anomalies: 2x normal duration or over 60 seconds absolute
• Retry logic: max 2 retries with exponential backoff (5s, 15s)
• Manual review: any push failing 3 times needs root cause analysis

Prevent future rejections with branch protection and pre-push hooks

Set up branch protection on critical branches to catch issues before they reach the remote. Enable 'Require pull request reviews' and 'Require status checks to pass' in your hosting provider's settings. This forces code review and CI validation before any push reaches main or production branches.

Add a local pre-push hook to run fast checks before Git contacts the remote. Create .git/hooks/pre-push with a script that runs linters or unit tests. If the hook exits non-zero, Git aborts the push. This saves round-trip time—catching a linting error locally in 2 seconds instead of pushing, waiting 10 seconds, then seeing the remote hook reject it.

An example pre-push hook for a Node project: #!/bin/sh followed by npm run lint && npm test. Make it executable with chmod +x .git/hooks/pre-push. If tests fail, the push stops before network transfer. On a medium repo this cut failed push attempts from 8 per day to 1 per day because developers caught issues before pushing.