Git rebase

In addition to the git merge command, there is another way to merge branches. This is git rebase. It is used for the same purpose to merge changes made in one branch into another. However, the principles of these methods are different, each of them has its own pros and cons. Therefore, in different situations, it makes sense to choose one of the two. Below we will analyze the difference between these commands in more detail and learn how to use git rebase.

Merge vs rebase

The difference between these commands may be subtle at first glance. So let's look at an easy funny example with pictures to make it clearer. Let's say we have a task to make a beautiful ginger cat with a bow. The cat is being developed on two branches. In the main branch, we consistently draw a cat and at the last stage add a bow to it. And in another branch, for example, in a feature, we paint the cat. When we have drawn and colored everything, we can merge the branches.

If we use the git merge command, we get as in the first part of the picture, two branches together and their result is a completely colored cat with a bow. We see the entire history of cat development with all stages.

Now let's go back and try to use git rebase. We have two branches with different modifications of the cat and what we have at the end is one main branch with the final cat version. The story is silent about the fact that there was still a branch with a red-colored cat. We just moved what we needed and removed everything in between.

This is the main difference between these commands. The first one merges two branches and stores the entire history of changes. Thus, we have the ability to track our every step. The downside is that it's easy to get confused in such a long history with branches.
The second command moves only the most important to the target branch and rewrites history so that some parts of it just disappear. The advantage of the git rebase command is that we will never get lost in commits. It is very convenient and economical for large projects where you need to code and commit a lot.

How git rebase works

When you run git rebase, Git takes the commits from the current branch that aren’t in the target branch and re-applies them one by one on top of the target branch’s HEAD. This process rewrites commit history by creating new commit IDs for each rebased commit. Here are some important points to remember:

• Rebase creates a straight, linear progression of commits. This clean history can make it easier to understand the evolution of your project;

• Since rebase rewrites commit history, it’s best used on local or private branches. Avoid rebasing commits that have already been published to a shared repository, as this can lead to conflicts and confusion among collaborators;

• If conflicts occur during a rebase, Git will pause the process. You must resolve the conflicts and then use: git rebase --continue

• If needed, you can cancel the rebase with git rebase --abort

Rebase usage

In the simplest case, to apply rebase, you need to write the following commands in the terminal:

$ git checkout feature
$ git rebase main

And if you need to feel more control and power over commits, then you can do this:

$ git checkout feature
$ git rebase -i main

Thus, it will be possible to change commits when they are moved to a new branch. Typically used to clear history before merging feature branch into main. Right after these commands, you will see an editor listing all the commits that will be moved.

pick 48g8m10b Commit message #1

Specifically, you will see a list of such commits, where the sequence of numbers 48g8m10b is the commit identifier, Commit message#1 is the message, and the pick command means "use this commit". What else can you do with a commit? You can change the message using the reword command, you can remove the commit using the drop command or you can squash it in order to use it but meld into the previous one. The last command is especially useful if you are using a gitflow model and want to add new features to your develop or release branch. This will keep your story clean. A complete list of commands with their descriptions will be available to you in the editor itself.

Conclusion

In the early stages of mastering git rebase, it may seem difficult and challenging. However, when you start participating in large team developments, you will appreciate its beauty. To have a clean and understandable commit history, it's better to use git rebase, but do remember to use it wisely.