How to Handle “Push Rejected” Conflicts

This guide covers the common scenario where you make changes locally, try to push, but Git rejects your push because someone else (or you on another machine) has already pushed changes to the same branch.

The Problem

You see errors like:

! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

Or:

! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.

Why This Happens

  1. Multiple machines: You worked on laptop, pushed, then worked on desktop without pulling

  2. Team collaboration: Someone else pushed changes while you were working

  3. Forgot to pull: Started working without getting latest changes first

  4. Auto-sync conflicts: Cloud sync or other tools created conflicts

Quick Assessment Commands

Before fixing, understand the situation:

# See current status
git status

# See what's different between local and remote
git fetch origin
git log --oneline --graph HEAD origin/master

# See exactly what conflicts exist
git log HEAD..origin/master --oneline  # What remote has that you don't
git log origin/master..HEAD --oneline  # What you have that remote doesn't

Solution Methods (Ranked by Safety)

Method 1: Pull with Merge (Safest, Preserves History)

Best when: You want to preserve all history and see the merge in the log.

# Fetch latest changes
git fetch origin

# Pull and create merge commit
git pull origin master
# OR explicitly:
git merge origin/master

# If there are conflicts, resolve them (see conflict resolution below)
# Then push
git push origin master

Result: Creates a merge commit showing both lines of development.

Method 2: Pull with Rebase (Clean History)

Best when: You want linear history and your commits are small/clean.

# Fetch latest changes
git fetch origin

# Rebase your changes on top of remote changes
git pull --rebase origin master
# OR explicitly:
git rebase origin/master

# If there are conflicts, resolve them (see rebase conflict resolution below)
# Then push
git push origin master

Result: Your commits appear after the remote commits, linear history.

Method 3: Reset and Re-apply (Nuclear Option)

Best when: Your local changes are experimental or easily recreated.

# Save your work first!
git stash push -m "My work before reset"

# Reset to match remote
git fetch origin
git reset --hard origin/master

# If you want your changes back:
git stash pop

# Resolve any conflicts and commit again
git add .
git commit -m "Re-apply my changes after sync"
git push origin master

Result: Loses your commit history but preserves your changes.

Conflict Resolution Guide

Merge Conflicts

When you see:

Auto-merging filename.txt
CONFLICT (content): Merge conflict in filename.txt
Automatic merge failed; fix conflicts and then commit the result.

Step-by-step resolution:

  1. Check which files have conflicts:

    git status
    # Shows files under "both modified" or "unmerged paths"
    
  2. Open conflicted files and look for conflict markers:

    <<<<<<< HEAD
    Your changes
    =======
    Remote changes
    >>>>>>> origin/master
    
  3. Resolve conflicts:

    • Keep your changes: Delete conflict markers and remote content

    • Keep remote changes: Delete conflict markers and your content

    • Keep both: Merge both sets of changes meaningfully

    • Create new solution: Write something entirely new

  4. Mark as resolved and complete merge:

    git add conflicted-file.txt
    git status  # Should show "All conflicts fixed but you are still merging"
    git commit  # Uses default merge message or customize it
    
  5. Push the resolved merge:

    git push origin master
    

Rebase Conflicts

When rebasing, you might see:

CONFLICT (content): Merge conflict in filename.txt
error: could not apply abc1234... Your commit message

Step-by-step resolution:

  1. Resolve conflicts (same as merge conflicts above)

  2. Continue the rebase:

    git add conflicted-file.txt
    git rebase --continue
    
  3. If more conflicts exist, repeat steps 1-2

  4. If you want to abort:

    git rebase --abort  # Returns to state before rebase
    
  5. Push after successful rebase:

    git push origin master
    

Real-World Examples

Example 1: Simple File Edit Conflict

Scenario: You edited build-certs.sh on your laptop, someone else edited it and pushed.

# Your situation
git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.

git push origin master
# ! [rejected] master -> master (fetch first)

# Solution using merge
git fetch origin
git pull origin master
# Auto-merging build-certs.sh
# CONFLICT (content): Merge conflict in build-certs.sh

# Edit build-certs.sh to resolve conflicts
vim build-certs.sh

# After resolving conflicts
git add build-certs.sh
git commit -m "Merge remote changes in build-certs.sh"
git push origin master

Example 2: Different Files, No Conflicts

Scenario: You edited README.md, someone else edited CHANGELOG.md.

git push origin master
# ! [rejected] master -> master (fetch first)

# Easy solution - should merge automatically
git pull origin master
# Merge made by the 'recursive' strategy.
#  CHANGELOG.md | 5 +++++
#  1 file changed, 5 insertions(+)

git push origin master
# Success!

Example 3: You Want Clean History

Scenario: You made several small commits, want them to appear after remote changes.

git log --oneline -5
# abc1234 Fix typo in documentation
# def5678 Update version number  
# ghi9012 Add new feature

git push origin master
# ! [rejected] master -> master (non-fast-forward)

# Use rebase for clean history
git fetch origin
git rebase origin/master
# Successfully rebased and updated refs/heads/master.

git push origin master
# Success! Your commits now appear after remote commits

Example 4: Multiple Machines Scenario

Scenario: You worked on desktop, pushed, then worked on laptop forgetting to pull.

# On laptop (forgot to pull)
git log --oneline -2
# Desktop: aaa1111 Fixed bug on desktop
# Laptop:  bbb2222 Added feature on laptop

# Try to push
git push origin master
# ! [rejected]

# See the situation
git fetch origin
git log --oneline --graph HEAD origin/master
# * bbb2222 (HEAD -> master) Added feature on laptop
# | * ccc3333 (origin/master) Another fix from desktop  
# | * aaa1111 Fixed bug on desktop
# |/

# Rebase to put laptop work after desktop work
git rebase origin/master
git push origin master

Prevention Strategies

1. Always Pull Before Starting Work

# Good habit - start every session with:
git checkout master
git pull origin master
# Then create feature branch or work directly

2. Use Feature Branches

# Instead of working on master directly:
git checkout -b feature/my-work
# ... make changes ...
git push origin feature/my-work

# Then merge through pull request or:
git checkout master
git pull origin master  # Get latest
git merge feature/my-work
git push origin master

3. Configure Pull Behavior

# Set pull to always rebase (avoids merge commits)
git config --global pull.rebase true

# Or set pull to fast-forward only (fails if rebase needed)
git config --global pull.ff only

4. Use Git Hooks

Create .git/hooks/pre-push to check for updates:

#!/bin/bash
# Check if remote has changes before pushing

protected_branch='master'
current_branch=$(git rev-parse --abbrev-ref HEAD)

if [ $protected_branch = $current_branch ]; then
    git fetch origin
    
    if [ $(git rev-list HEAD..origin/$current_branch --count) -gt 0 ]; then
        echo "🚫 Remote has changes you don't have locally!"
        echo "Run 'git pull origin $current_branch' first"
        exit 1
    fi
fi

Troubleshooting Common Issues

Issue 1: “Please enter a commit message to explain why this merge is necessary”

# This appears during git pull (merge)
# You're in an editor (usually vim)

# In vim:
# 1. Press 'i' to enter insert mode
# 2. Type your message or keep the default
# 3. Press Escape
# 4. Type ':wq' and press Enter

# To avoid this in future:
git config --global core.editor "nano"  # Use nano instead
# OR
git pull origin master -m "Merge remote changes"

Issue 2: “Your branch and ‘origin/master’ have diverged”

# This means both local and remote have unique commits
git status
# Your branch and 'origin/master' have diverged,
# and have 2 and 3 different commits each, respectively.

# Options:
# 1. Merge (creates merge commit)
git pull origin master

# 2. Rebase (linear history)
git pull --rebase origin master

# 3. See what's different first
git log --oneline --graph HEAD origin/master

Issue 3: Binary File Conflicts

# When binary files conflict (images, PDFs, etc.)
git status
# both modified:   image.png

# You must choose one version:
# Keep yours:
git checkout --ours image.png

# Keep theirs:
git checkout --theirs image.png

# Then complete the merge:
git add image.png
git commit

Issue 4: Accidentally Pushed to Wrong Branch

# If you pushed to master instead of feature branch:

# Create feature branch from current state
git checkout -b feature/my-work

# Reset master to remote state
git checkout master
git reset --hard origin/master

# Push the feature branch
git checkout feature/my-work
git push origin feature/my-work

Advanced Scenarios

Scenario 1: Conflicted Rebase with Multiple Commits

# During rebase, you might hit conflicts on multiple commits
git rebase origin/master
# CONFLICT in commit 1

# Resolve first conflict
git add conflicted-file.txt
git rebase --continue
# CONFLICT in commit 2

# Resolve second conflict  
git add another-file.txt
git rebase --continue
# Successfully rebased

git push origin master

Scenario 2: Complex Three-Way Conflicts

# When you, remote, and common ancestor all differ
# Conflict markers show three sections:

# <<<<<<< HEAD (your changes)
# Your code
# ||||||| base (common ancestor)  
# Original code
# =======
# Remote changes
# >>>>>>> origin/master

# Resolve by understanding all three versions

Scenario 3: Recovering from Bad Merge

# If you completed a merge but want to undo it
git log --oneline -3
# abc1234 Merge branch 'master' of origin into master
# def5678 Your commit
# ghi9012 Remote commit

# Undo the merge (before pushing)
git reset --hard HEAD~1  # Goes back to before merge

# Or if you already pushed:
git revert -m 1 HEAD  # Creates new commit undoing the merge

Best Practices Summary

  1. 🔄 Always pull before starting work

  2. 🌿 Use feature branches for significant work

  3. 📊 Check status before pushing: git status and git log --oneline -5

  4. 🔍 Understand conflicts: Don’t just accept changes blindly

  5. 💾 Backup important work: Use git stash or create branches

  6. 📝 Write good commit messages: Helps during conflict resolution

  7. 🤝 Communicate with team: Let others know about major changes

Quick Reference Cheat Sheet

# Emergency commands
git fetch origin                    # Get remote info without merging
git stash                          # Save current work temporarily
git status                         # See current state
git log --oneline --graph -10      # See recent history

# Resolution commands
git pull origin master             # Merge remote changes
git pull --rebase origin master    # Rebase local changes on remote
git add .                          # Stage resolved conflicts
git commit                         # Complete merge
git rebase --continue              # Continue rebase after conflict
git rebase --abort                 # Abort rebase, return to original state

# Recovery commands
git reset --hard origin/master     # Nuclear: match remote exactly
git reflog                         # See all recent Git operations
git checkout HEAD~1                # Go back one commit

Remember: When in doubt, create a backup branch before trying any of these solutions:

git checkout -b backup-before-fix
git checkout master
# Then proceed with conflict resolution

This way you can always recover if something goes wrong!