Why you should always rebase your feature branches

the-power-of-rebase

The question always comes up, especially with the newer developers, should I run git rebase or git merge?

Easy answer…

Always Rebase feature branches.

Merges can cause problems!

What problems? Well, you just wrote great code, but your release branch is now trying to overwrite that with a merge, and unless it hits a conflict, you’ll never know!

Rebase is the best way to keep your history intact.

Plus, seeing a ton of merge commits in a branch history and arrows is annoying and very messy!

See how much cleaner a rebase is?

Use these commands in your local to perform the rebase:

# first, be on your feature branch:
git checkout feature/ABC-123_feature_name
# now, rebase...
git fetch
git rebase origin/release/4.1  # Origin means the remote, and release/4.1 is whatever your release branch is
#...fix merge conficts... 
git add . && git rebase --continue   # Only necessary when you have conflicts
# last step- CAREFUL with the force-push option. If you're on any other branch by accident
# you could create problems.
git push -f   # See explanation below

*I’ve seen beginners try to do these steps, but they don’t force-push their rebased branch at the end. So instead, git responds with what appears to be an error message like this:

Don’t believe it! git’s hint is trying to trick you!!!!

If you see this DON’T git pull!!

That will completely defeat what you just did with the rebase!

In other words, what this means is that the remote version of your branch is WRONG.

After you successfully rebase, doing the force-push with git push -f will overwrite the remote version with the work you have just updated locally.

Related articles