In this post, you’ll know how to perform a successful git push after rebase. Pushing changes to the remote origin is nothing new. But there are some situations where the push may be rejected. Or it can override someone else’s progress.
After you rebase, the commit history changes. So you need to push with the “–force” flag. If you encounter a “git push rejected” error after rebasing a feature branch, here are some steps you can follow to fix it.
Double-check your changes
After rebasing a feature branch, ensure you have resolved conflicts and staged the changes using the git add -A command.
Update your local branch
Ensure that your local branch is up-to-date with the latest changes from the remote repository. You can do this by running git pull command to fetch. And you can merge the latest changes from the remote repository into your local branch.
If it helped you, please share this post on your website.
Perform a forceful push after git rebase
This is the advice that I gave you at the very beginning of this post. Since you have rebased your feature branch, the commit history changed. So you need to force-push your changes to the remote repository.
You can do this using git push command with the “-f” or “--force” flag. See the example below:
git push origin branch_name --force
Or git push -f origin branch_name
You have to replace the branch_name with the actual name.
Communicate with your team
If you are working in a team, it’s very important to communicate with other members before you do a forceful push. Because it can affect others who have cloned or pulled the repository.
Make sure everyone is aware of the changes you are making and coordinate accordingly.
Instead of the “--force“, there is a better alternative which is “--force-with-lease.” The difference is you’ll get a warning if anyone else made a commit to the same branch.
Resolve any further issues
Only pushing with a “--force” flag is not always the solution. Sometimes it can be dangerous if you’re not sure what you’re doing.
Not only after rebase but also every time you perform a git push with the “--force” flag, you have to make sure that you’re not bringing everyone (team members) to the same day when they get started.
After you confirm these factors and if the push is still rejected, double-check for any other issues, such as:
- Permissions
- Branch protection rules
- Other configuration settings on the remote repository
If necessary, consult with your team or repository administrator to resolve any further issues.
Learn more about Git
- What is Git and why it is used?
- How to install Git on Windows & Mac?
- How to use Git with Visual Studio Code?
- How to use Git and GitHub?
- What is the difference between Git and GitHub?
- How to connect local Git to a remote server?
- How to change Git remote origin URL?
- How to create a Git repository on GitHub?
- Git add all (stage all changes)
- How to undo the git add -A command?
- How to undo the last Git commit?
- How to change the git commit message?
- How to remove or unstage a file from Git commit?
- How to git push after rebase?
- Git switch branches: How to checkout the git branch?
- How to merge a git branch to master?
- Git branch: create, checkout, merge, list, command, delete & push
- How to clone a Git repository?
- How to git pull to override the local project?
- How to remove file from Git?
- When should you use git rebase?
- Git commands & explanation (downloadable cheatsheet included)
- How to create GitHub Pages?
Conclusion
If you’re the only person who is working on a branch, then it’s okay to rebase a feature branch and perform a force push to the master.
If you know what exactly you’re doing and if you’re sure that you’re not going to override someone else’s work, don’t hesitate to perform a forceful git push after the rebase (--force). But if you have confusion, make the push with the --force-with-lease flag.
