# 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.
    
    ```
    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.
    
    ```
    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.
    
    ```
    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.
    
4. **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.
    
    ```
    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**
    
    ```
    git checkout feature-x
    ```
    
2. **Fetch Latest Changes**
    
    ```
    git fetch origin
    ```
    
3. **Force Push the Rebased Branch**
    
    ```
    git push origin feature-x --force
    ```
    
    Alternatively, for a safer approach:
    
    ```
    git push origin feature-x --force-with-lease
    ```
    
4. **Verify Push**
    
    Ensure the push was successful and the branch on the remote is updated:
    
    ```
    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.