Unlike the Git merge command, rebase involves rewriting your project history.
It’s a great tool, but don’t rebase commits other developers have based work on.
The Gitrebasecommand combines two source code branches into one.
fatmawati achmad zaenuri/Shutterstock.com
The Gitmergecommand does that too.
We explain whatrebasedoes, how it’s used, and when to usemergeinstead.
He named it Git.
Dave McKay/How-To-Geek
Sites likeGitHub,GitLab, andBitBuckethave symbiotically promoted and benefited from Git.
One of Git’s main design decisions was speed.
In particular, working with branches had to be as fast as possible.
Branches are a fundamental part of version control systems.
A project repository will have a main or master branch.
This is where the project’s code base sits.
Dave McKay/How-To Geek
Development, such as new features, takes place in segregated side branches.
What was once a tedious and often avoided exercise in other systems, became trivial in Git.
The Gitrebasecommand is another way of transferring the changes from one branch into another branch.
Dave McKay/How-To Geek
Themergeandrebasecommands have similar objectives, but they achieve their ends in different ways and yield slightly different results.
What Is Git merge?
So what isthe Gitmergecommandfor?
Dave McKay/How-To Geek
Let’s say you’ve created a branch calleddev-branchto work on a new feature.
Youmake a few commits, and test your new feature.
It all works well.
Dave McKay/How-To Geek
Now you want to send your new feature to themasterbranch.
You must be in themasterbranch to merge another to it.
We can ensure we’re in themasterbranch by explicitly checking it out before we merge.
Dave McKay/How-To Geek
We can now tell Git to merge thedev-branchinto the current branch, which is themasterbranch.
Ourmergeis completed for us.
If you checkout themasterbranch and compile it, it’ll have the newly developed feature in it.
What Git has actually performed is a three-way merge.
it compares the most recent commits in themasteranddev-branchbranches, and the commit in themasterbranch immediately before thedev-branchwas created.
It then performs a commit on themasterbranch.
Thedev-branchstill exists, and none of the previous commits are altered.
A new commit is created that captures the results of the three-way merge.
Thedev-branchbranch has been incorporated into themasterbranch.
If you have a lot of branches in one project, the history of the project can become confusing.
This is often the case if a project has many contributors.
Because the development effort splits into many different paths, the development history is non-linear.
Untangling the commit history becomes even more difficult if branches have their own branches.
You could create a new branch and commit the changes there, and then do the merge.
You’d then need to merge your temporary branch back into the master branch.
What Is Git rebase?
The Gitrebasecommandachieves its aims in a completely different way.
Taking our previous example, before we performed any action our Git repository looks like this.
We have a branch calleddev-branchand we want to move those changes to themasterbranch.
After therebase, it looks like a single, completely linear timeline of changes.
Thedev-branchhas been removed, and the commits in thedev-branchhave been added to the master branch.
The commits aren’t just tacked onto themasterbranch, they’re “replayed” and added fresh.
This is why therebasecommand is considered destructive.
you might’t determine at some later point which commits were originally made to thedev-branch.
However, it does leave you with a simplified, linear, history.
How to Rebase Onto Another Branch
Let’s try agit rebaseexample.
We’ve got a project with a branch callednew-feature.
We’drebasethat branch onto themasterbranch like this.
First, we check that themasterbranch has no outstanding changes.
We tell Git torebasethe current branch onto the master branch.
We can see that we have still got two branches.
Interestingly, we’ve still got two branches after the final merge.
Git Rebase vs.
Merge: Which One Should You Use?
It’s not a case ofrebasevs.merge.
They’re both powerful commands and you’ll probably use them both.
That said, there are use cases whererebasedoesn’t really work that well.
Unpicking mistakes brought on by mistakes usingmergeare unpleasant, but unpicking errors caused byrebaseis hellish.
You could stillrebasein the wrong direction for example, andrebaseyour master branch onto yournew-featurebranch.
To get yourmasterbranch back, you’d need torebaseagain, this time from yournew-featurebranch to yourmasterbranch.
That would restore yourmasterbranch, albeit with an odd-looking history.
Don’t userebaseon shared branches where others are likely to work.
Likewise, if pull requests form part of your code reviews, don’t userebase.
Or at least, don’t userebaseafter creating the pull request.
Your localrebasewill make those existing commits vanish.
If you push those changes to the repository you’re not going to be popular.
Other contributors will have to go through a messymergeto get their work pushed back to the repository.
To Rebase, or Not to Rebase?
Rebasemight be outlawed in your project.
There may be local, cultural objections.
Some projects or organizations considerrebaseas a form of heresy, and an act of desecration.
Some people believe the Git history should be an inviolable, permanent record of what has happened.
So,rebasemight be off the table.
But, used locally, on private branches,rebaseis a useful tool.
Push after you’ve rebased, and restrict it to branches where you’re the only developer.
Do that and you’ll avoid any issues.
Related:How to Check and patch your Git Version
