How to git rebase main/master onto your feature branch even with merge conflicts


September 04, 2021 / 2 min read / 157,567 views, 30 likes, 27 comments

Last updated: September 30, 2022

Tags: git


Git rebase

Does your project prefer git rebase instead of git merge? Has your branch fallen out of sync with the main branch and you are unable to automate your rebase due to conflicts? If so, you might have run into rebase hell. This happens when you try to git rebase, solve your conflicts, and push to the main branch, only to find that the main branch is now, once again, out of sync in a never-ending loop. Let's break out of rebase hell with this short guide to rebasing.

The steps

  1. Go to the branch in need of rebasing
  2. Enter git fetch origin (This syncs your main branch with the latest changes)
  3. Enter git rebase origin/main (or git rebase origin/master if your main branch is named master)
  4. Fix merge conflicts that arise however you see fit
  5. After fixing merge conflicts, git add FILE previously merge conflicted files
  6. Enter git rebase --continue (or git rebase --skip if git complains that there were no changes after resolving all conflicts)
  7. Repeat as necessary as merge conflicts arise in the subsequent commits
  8. Once the rebase is complete, enter git push origin HEAD --force

    This command pushes your rebase fixed branch to remote. The --force is important as it tells remote, "I know these changes are correct, accept them as is." Without the --force flag, your remote branch will continue to believe it is out of sync and will claim a merge conflict.

And that's it. You have now git rebased the main branch onto your feature branch and broken yourself out of rebase hell.


About the author


Theodore Williams

Hi, my name is Teddy Williams. I'm a software developer with a special love for python programming. πŸπŸ‘¨β€πŸ’» I have a wide range of programming interests including web development, hobby video game development, IoT, data science and just writing scripts to automate everyday boring tasks. I'd love it if you check out some of my other posts or take a look at my portfolio! :)

Thanks for reading this post! πŸ’š If you like the post, let me know by hitting the icon below, and if you have any questions or comments I'd love to hear them in the comments section. Thanks, and happy coding! πŸŽ‰

like post (30) Comments (27)


Log in to comment with your own custom profile. That way you can edit and delete your comments. Plus you can pick out a fun profile picture to show-off next to your comment. πŸ˜ƒπŸ€–πŸ‘½πŸ˜» Not Registered? It's easy! πŸ€“ Or... fast-comment without a login below (no comment editing/deleting πŸ’©).

User avatar not found

User avatar not found Brey | July 14, 2022 01:24 PM

I'm just registered to write u a thank you message, you saved me from another 8 hours of headache (or more?), thanks man!

reply

User avatar not found verdantfox | July 20, 2022 11:37 PM

Awesome to hear it! Thanks mate! πŸ˜€

Vikram | October 03, 2022 10:52 AM

Lovely post! You made my day. I always used to do "merge" and "rebase" is new to me and this helps a novice user for "rebase". Though I found a similar post and guide, step-7 in your post "Repeat as necessary as merge conflicts arise in the subsequent commits" helped to understand more clearly that "rebase" is something to deal with each commit I've in my feature branch and just like "merge" that does everything-at-once!

reply

User avatar not found verdantfox | October 03, 2022 01:49 PM

Glad the post was helpful to you. πŸ™‚

Vinayak K | October 28, 2022 11:28 AM

IMO --force-with-lease is a better option in this context than --force

reply

User avatar not found verdantfox | October 29, 2022 12:29 AM

Interesting. I hadn't heard of --force-with-lease. Looking into it, I think you might be right. In most cases it wouldn't change anything, but if you happened to have multiple developers working on the feature branch at the same time it could save some headache. Here's a stack overflow post about the difference for anyone reading this interested: https://stackoverflow.com/questions/52823692/git-push-force-with-lease-vs-force

Mert | November 02, 2022 12:24 PM

After a year, I still get back this page and look how to rebase! Thanks man, really thanks :)

reply

User avatar not found verdantfox | November 02, 2022 01:56 PM

I'm so glad it has been helpful for you Mert! Thanks, I appreciate the feedback. :-)

Davis | January 26, 2023 06:08 PM

Thanks! Thought I was gong crazy for a moment before I found this page lol

reply

User avatar not found verdantfox | February 05, 2023 01:38 AM

I'm glad it could help Davis! Thanks for the positive feedback. πŸ™‚

Sardor | October 10, 2023 08:42 AM

thanx man , helped a lot

reply

User avatar not found verdantfox | October 10, 2023 01:35 PM

You're welcome Sardor, I'm glad it helped. πŸ˜ƒ

Anton | November 02, 2023 08:59 AM

Hey, this was very simple and nice, in our day-to-day life we usually work on our feature branch and then we regularly need to rebase as it is sometimes quite common among developers. But at the same time, it is confusing to developers who are used to merging rather than rebasing. So for those group, this is very easy and simple to follow. Thanks.

reply

Amr | November 26, 2023 01:16 PM

Thanks Bro <3

reply

User avatar not found GeorgeM | November 30, 2023 05:43 PM

Hi Teddy, my main branch is master on our production server. I have merged all development changes on the master branch on GitHub and resolved all conflicts. Will pulling master from GitHub to the production server simply overwrite master on production or will I have the same 200 plus merge conflicts to resolve all over again?

reply

User avatar not found verdantfox | November 30, 2023 06:02 PM

If I understand the question correctly, it'll overwrite without new merge conflicts. As long as you haven't made local changes to your main branch (ie there are extra commits on your server's main branch compared to the remote source), I believe pulling the main branch will always sync your local (server) main branch with the HEAD of the remote main branch.

User avatar not found GeorgeM | December 01, 2023 01:28 PM

Thanks Teddy, that's what I thought would happen with the merge from GitHub to our production server. This is a major rewrite, necessitating an outage while installing the new site. I want to keep the outage window as short as possible.

reply

Christian Galaz | January 08, 2024 03:23 PM

Muchas gracias por tu aportaciΓ³n, me has quitado muchos dolores de cabeza

reply

User avatar not found verdantfox | January 08, 2024 03:27 PM

De nada. Me alegro de poder ayudar.

User avatar not found carla | January 17, 2024 03:21 PM

Thank you for the explanation comments next to the commends, that's vital info!

reply

Mots | February 20, 2024 09:39 AM

Can you quote examples on how to merge conflicts with theirs vs ours if I'm re basing master on my feature branch. It always confuses what is ours and theirs and I read somewhere the context changes in rebase vs merge.

reply

User avatar not found verdantfox | February 20, 2024 03:01 PM

Interesting, I didn't realize there were differences in "ours" vs. "theirs" in rebase vs. merge. Sorry, I'm not going to go into details on solving merge conflicts for this post. I hope you can sort out the problem, though. Best of luck.

Eva | March 19, 2024 08:01 PM

Thank you! Finally a clear easy path to do this thing I've struggled to do correctly for years.

reply

User avatar not found verdantfox | March 20, 2024 10:23 PM

I'm so glad the post was helpful for you! :)

Wenny | March 22, 2024 10:44 AM

Thank you for this clear and concise post! It definitely got me out of the rebase hell - now I'm not afraid of rebasing anymore 😀

reply

User avatar not found verdantfox | March 22, 2024 01:39 PM

I'm glad it was helpful, Wenny! πŸŽ‰

K | April 16, 2024 04:39 PM

Nice

reply