What rebasing does and why you might need it

Rebasing takes the changes you made in your branch and replays them on top of the current main branch, one commit at a time. When two people edit the same lines in the same file, Git cannot automatically decide which version to keep — that is a merge conflict. Rebasing forces you to resolve those conflicts as Git replays your commits, rather than trying to merge two versions at once.

The practical difference: a merge creates a new commit that ties two histories together. A rebase rewrites your branch's history so it looks like you made your changes after someone else made theirs. Both end up in the same place, but rebasing keeps the history cleaner and easier to read later.

You might rebase instead of merge if your team prefers a linear history, if you want to clean up your own commits before sharing them, or if you are pulling in changes from main and want to avoid a tangle of merge commits. The tradeoff is that rebasing rewrites history, which can confuse teammates if you rebase a branch they are also working on.

Key Takeaways

  • Rebasing replays your commits on top of the latest main branch, which forces you to resolve conflicts commit by commit instead of all at once.
  • Start a rebase with git rebase main (or whatever branch you are rebasing onto), and Git will pause at each conflict and tell you which files have problems.
  • After you fix each conflict by editing the file, stage it with git add, then continue the rebase with git rebase --continue.
  • If a rebase goes wrong, you can undo it completely with git rebase --abort and return to where you started.
  • Never rebase a branch that other people are actively working on, because rewriting history will break their local copies.

Starting a rebase and understanding what Git shows you

Before you rebase, make sure you are on your own branch, not on main. Type git branch to see which branch you are currently on — it will have an asterisk next to it. If you are on main, switch to your branch with git checkout your-branch-name.

Now type git rebase main. Git will start replaying your commits on top of main, one at a time. If there are no conflicts, it finishes silently and you are done. If there is a conflict, Git stops and tells you which files have problems. Open those files in your text editor.

Inside the file, you will see sections marked with <<<<<<<, =======, and >>>>>>>. The section between <<<<<<< and ======= is your change. The section between ======= and >>>>>>> is the change from main. You need to decide which one to keep, or combine them, or rewrite them entirely.

Resolving each conflict by hand

There is no automatic right answer — you have to read the code and decide what makes sense. Sometimes you keep your version. Sometimes you keep theirs. Sometimes you need both, or you need to rewrite the section so it works with both changes.

Once you have fixed the file, delete the conflict markers (<<<<<<<, =======, >>>>>>>) and save the file. Then tell Git you have resolved the conflict by typing git add filename. You do not need to commit — just stage the file.

If the same file has multiple conflict sections, fix them all before staging. If multiple files have conflicts, fix and stage each one. Once you have staged all the fixed files, type git rebase --continue. Git will move to the next commit in your branch and check for conflicts again.

Repeat this process — fix conflicts, stage files, run git rebase --continue — until Git tells you the rebase is complete. You will see a message like "Successfully rebased and updated refs/heads/your-branch-name".

When to abort and start over

If you get partway through a rebase and realize you made a mistake, or the conflicts are too tangled to sort out, you can undo the entire rebase with git rebase --abort. This returns your branch to exactly the state it was in before you typed git rebase main. Nothing is lost.

Aborting is the right move if you realize you need to talk to a teammate about which version to keep, or if you want to try a different approach. There is no penalty for starting over.

Pushing your rebased branch and avoiding conflicts with teammates

After a successful rebase, your branch is ready to push. However, because rebasing rewrites history, you cannot use a normal git push — Git will refuse because your local history no longer matches what is on the server. Instead, type git push --force-with-lease.

The --force-with-lease flag is safer than --force because it checks whether anyone else has pushed to this branch since you last pulled. If they have, it stops and tells you, so you do not accidentally overwrite their work.

This is why you should never rebase a branch that other people are actively working on. If you rebase and force-push, their local copies will be out of sync with the server, and they will have to do extra work to fix it. If you are the only person on a branch, rebasing is safe and clean.

Rebasing versus merging: when to use each

Rebasing keeps history linear and readable — when you look back at the log, you see a straight line of commits in order. Merging keeps both histories visible — you see a branch point and a merge commit that ties them back together.

Teams that prefer rebasing usually have a rule: rebase your own branches before you merge them into main, but never rebase main itself. Teams that prefer merging accept that history will have branch points, but they never lose information about when parallel work happened.

If your team has not said which one to use, ask. If you are working alone, either is fine — pick whichever one you find easier to understand. The important thing is that conflicts get resolved and the code works.

Frequently Asked Questions

What if I have already pushed my branch and then I rebase it?

You will need to force-push with git push --force-with-lease to update the server. If anyone else is working on this branch, tell them first so they know to pull again. If you are the only person on the branch, just force-push and move on.

Can I rebase onto a branch other than main?

Yes. Type git rebase branch-name to rebase onto any branch. This is useful if you are working on a feature that depends on another feature branch that is not yet merged into main.

What does "git rebase --continue" do if there are no more conflicts?

It moves to the next commit in your branch. If there are no more commits to replay, the rebase finishes and Git tells you it is complete. If the next commit also has conflicts, Git stops again and shows you the conflict markers.

Is rebasing dangerous?

Rebasing is safe as long as you are the only person working on the branch. It only becomes dangerous if you rebase a shared branch and force-push, because that rewrites history for everyone. Always check with teammates before rebasing a branch they might be using.

Can I undo a rebase after I have already pushed it?

Yes, but it is messy. Git keeps a log of where your branch pointed before the rebase. Type git reflog to see the history, find the commit hash from before the rebase, and type git reset --hard hash to go back. Then force-push with git push --force-with-lease. Tell your teammates what happened so they can pull again.