Git Push Rejected After Feature Branch Rebase

When you rebase a feature branch and then try to push it to a remote repository, you might encounter a rejected error. This occurs because the rebase operation rewrites the commit history of your feature branch, making it different from the version of the branch that exists on the remote. Git is preventing you from pushing because it wants to avoid overwriting commits that may exist on the remote.

Here's how you can handle this situation:

Understanding the Problem

• Rebase vs. Merge: A rebase rewrites the commit history by changing the base of your branch, while a merge creates a new commit that combines the histories. Rebasing can change commit hashes, leading to conflicts with the remote branch that still has the old commit history.
• Push Rejected: When you attempt to push after a rebase, Git rejects the push because the remote branch history does not match your local branch's new history.

Steps to Resolve the Push Rejection

1. Ensure You’re on the Correct Branch

   Make sure you're on the branch that you rebased and want to push.

    

   Copied!

   git checkout <your-feature-branch>
   

2. Fetch Remote Updates

   It's good practice to fetch updates from the remote before pushing, to ensure you have the latest changes.

    

   Copied!

   git fetch origin
   

3. Force Push Your Changes

   Since the rebase has rewritten history, you need to use a force push to update the remote branch. This will overwrite the remote branch with your local branch's history.

    

   Copied!

   git push origin <your-feature-branch> --force
   

- `-force` (or `f`): This option forces the push even if it will overwrite the remote branch's history.

**Note**: Use `--force` with caution. It can overwrite changes on the remote branch, potentially impacting other collaborators who might be working with the branch.

1. Alternative - Use -force-with-lease

   To prevent accidentally overwriting changes that you’re not aware of, you can use --force-with-lease instead of --force. This option ensures that you only push if the remote branch hasn’t changed since you last fetched.

    

   Copied!

   git push origin <your-feature-branch> --force-with-lease
   

   This is a safer option as it checks the state of the remote branch before pushing.

Example Workflow

Assume you have a feature branch feature-x that you have just rebased and want to push to the remote.

1. Check Out the Feature Branch

    

   Copied!

   git checkout feature-x
   

2. Fetch Latest Changes

    

   Copied!

   git fetch origin
   

3. Force Push the Rebased Branch

    

   Copied!

   git push origin feature-x --force
   

   Alternatively, for a safer approach:

    

   Copied!

   git push origin feature-x --force-with-lease
   

4. Verify Push

   Ensure the push was successful and the branch on the remote is updated:

    

   Copied!

   git branch -r
   

Summary

When you rebase a branch and encounter a push rejection, it’s because the rebase changes commit history. To resolve this:

1. Fetch remote changes to ensure you have the latest state.
2. Force push the rebased branch with -force or -force-with-lease.

Always be cautious with force pushing, especially in shared repositories, as it can overwrite changes that other collaborators may be working with. Using --force-with-lease helps prevent accidental overwrites by ensuring that the remote branch has not changed since your last fetch.

Got an article suggestion? Let us know

Explore more

Git

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.