I've been using git for a long time and I've never had the case where I have to use rebase
, the only time I used them in a graphical tool it broke everything. Lately I have heard it mentioned very often but I don't fully understand it, if someone could explain its functionality it would be of great help.
Rebase is one of the best git commands ever... but to understand it, it's important to understand what's going on behind the scenes.
Rebase is very useful when you want to "rewrite history", and can be used in different scenarios.
Deal with failing to push when another developer pushed changes
It allows you to push your change without doing a merge commit when someone "beats you to the punch" by pushing. I wrote a post explaining this here .
Rebase a branch
Let's imagine that you have a project where it is
master
(where everyone works) and you create a branchpapafrita
. While other developers work on master, you work onpapafrita
. There comes a time when the status of your repository is as follows:One option to "pull" changes from
master
is to do itgit merge master
while inpapafrita
... but, that creates an ugly merge commit . That's what the beautiful is forgit rebase
. Being inpapafrita
, it is enough to do:And (if there are no conflicts) the result will be the following:
And ready! we have a much nicer story than if we had a horrible merge commit :)
Squash (or "squash") multiple commits
Let's imagine that at one point you find a bug, you fix it and then you realize that you actually introduced another bug... By fixing the initial fix, you are left with the following state in your repository:
This is ugly . Why? because commits 3 and 4 are of no value to a person trying to understand what happened in the history of the project. go? yes, sure... but for some obsessives, it's much better to have a meaningful story, where the commits "tell a story".
With
rebase
, you can rewrite the history, which is very dangerous if you are pushing to a remote repository ... with this it is always better to play before pushing so as not to earn the hatred of our peers.In this scenario, we can use
git rebase
to squash the commits. Squash means something like squashing them... creating a new commit, coming after 2, and similar to applying the changes from commits 3 and 4.In the console (yes... this does not work much for UI) you can do
-i
means "interactive mode", so it's going to open your configured text editor ( vim ornano
) and edit all commits untilHEAD~2
(HEAD
is "last",HEAD~2
is "last minus 2", so in the drawing would be commit 2).When you do this, you will see something like this:
Here you can see that you have the 2 commits we are working with and then a series of instructions. For each commit, you are going to say what you want to do. For the purposes of the
squash
, we're going to keep the newer one and squash the other... for that, just modify the file so that the first two lines are:When you save and exit, you will see that the editor opens again and shows you
This is your chance to define the commit message. If you leave it as is, it will be the message of the first commit followed by the second. If not, you can edit it to your liking. In this example, I am going to modify it to "Fixing the ugly bug"... so, the final state is:
And there's probably more magic you can do with
git rebase
... but I hope this helps show a couple of use cases where it's very useful.