Give up using Merge and happily embrace Rebase!

1 Introduction

Hello everyone, I am Bittao. As the most popular version management tool, Git must be used by everyone in the development process. Since many operations in Git are performed by Merge by default, and it is relatively less error-prone, many people will use Merge to merge code. However, as one of the main commands in Git, Rebase still needs to be understood and used in suitable scenarios.

2. The role of Rebase

Rebase Chinese translation: 变基, I think this translation is quite blunt, causing many people not to fully understand the meaning of rebase. Personally, I mean by Rebase 认爸爸, for example, you can rebase to the branch of Papa Ma and become his reasonable heir.

The picture above shows a rebase situation. You can see the final effect as if the Feature branch did not exist, and the newly submitted Commit looks like it was actually submitted on the main branch. And if we use Merge, a merge node will be generated:

it may be nothing to see the Commit node generated by only one merge, but in actual projects, there is a high probability that it will become like this: it

is a messy batch, as if seeing the Commit node many years ago A bunch of code written by other people, what, what, what is it! Conversely, look at real projects developed with Rebase. There is no harm without comparison:

This is why You Yuxi also recommends using rebase:

3. How to use Rebase

In fact, many people don't use Rebase. On the one hand, they don't understand how to use it in actual project collaboration. On the other hand, I have used it, but there are many problems, so I mistakenly think that it is not easy to use and never use it again. Let me share here, the collaborative process of Rebase that I recently adopted when working on a project (for the sake of illustration, it has been appropriately simplified):

3.1 Checkout

First of all, if we want to develop new functions or fix bugs from the master branch, we need to checkout a branch. For example,
checkout the dev branch in the A node, in order to make the scene more complicated, after git checkout dev the branch. Some people continued to submit B and C on the master, forming the following Git structure:

I want to emphasize here that many people have problems with rebase because they want the branch to be rebase to be a public branch. In fact, the dev here should only be suitable for the branch you use. Recall that Git itself is distributed version management. In fact, version control can be performed very well without remote warehouses. We need to distinguish the concepts of local branches and remote branches, which are not directly related. So you can just make an NB branch on your local machine. After rebase, no one will know what ghost name you gave yourself.

3.2 Remote Management

If our own dev branch is not necessarily developed on one computer, in order to develop on multiple computers by ourselves, we can associate a remote warehouse of our own. This step is optional.

3.3 Start rebasing

Now we have developed D and E on dev, and then dev rebase masterformed A, B, C, D, E:

although it seems to be a straight line here, in fact only dev knows that his father has become master, but master does not recognize this son. So we also need: master merge dev, so that a perfect straight line is formed on the master:

Finally, go git push origin masterto the remote branch to complete this development.

3.4 Aftercare

After rebase, dev has changed its base, which is equivalent to recognizing the thief as the father, and now you want to recognize it again? Don't think about it! So it can only be solved by force, forcing push to your own remote warehouse in the non-protected branch: git push --force origin dev, and finally rebase dev to your own remote branch: git rebase origin dev, to facilitate the maintenance of your own remote warehouse. So far, the development in the form of rebase has been completed, and the next development can be continued.

4. Advantages and disadvantages of Rebase

Let me talk about the advantages first:

• Keep the commit history linear: When merging branches with merge, a new merge commit is created, thus forming a new branch in the commit history. With rebase, the commit record can be added directly to the end of the target branch, thus maintaining the linearity of the commit history.
• Reduce unnecessary merge submissions: When using merge to merge branches, a new merge submission will be created, which may contain a lot of meaningless merge information. With rebase, the commit records can be added to the end of the target branch one by one, avoiding the creation of unnecessary merge commits.
• Better code review and traceability: With rebase, the commit history can be made more intuitive and understandable, making code review and issue traceability easier.
• Avoid conflicts: When merging branches, the merge may fail due to conflicts between the two branches. With rebase, these conflicts can be resolved before rebase, thus avoiding conflicts during merging.

In short, although rebase is not a universal solution for all situations, in most cases, using rebase can help us create a cleaner and more intuitive commit history and improve team collaboration efficiency.

Having said that, it seems to be talking about the advantages of Rebase, so does Rebase have no disadvantages? Of course not, otherwise everyone would have switched from Merge to Rebase long ago. Disadvantages of Rebase:

• Resolving conflicts is cumbersome. Rebase conflicts are compared on a per-commit basis, and merge conflicts are compared on the basis of the final result. If you use rebase, it is best to merge the code frequently. Otherwise, if you rebase at the end of long-term development, it will really be a problem. Solve the conflict until people are stupid.
• There is no merge record, but Merge has a record, so if there is a problem, it can be solved easily.
• The operation steps are relatively cumbersome.

5 Conclusion

The core issue of collaborative development is actually merging. How to merge reasonably and gracefully is a problem that every team needs to consider. As the main commands in Git, Merge and Rebase actually have their own advantages, and it is very common to use them together. According to your own team and project situation, it is best to choose the appropriate method. Finally, I wish you all the best in merging code~