Abstract: A frequent debate in git is whether to use rebase or merge?
1. Is it painful? The Lost Lamb in Code History
Let's first look at a graphical screenshot of the actual code submission history:
Picture from https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/c8b97f4dbb5f7d49fc3eb3624eafff79/london-tube-map-commit.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
I don’t know how you feel after seeing this picture? Is it very speechless? I feel speechless and choking. The code history has reached this point, and it is basically obsolete! ! !
Through this article we will talk about the issue of code history line. This involves a code history management problem. If you want to have a clearer code history so that you can quickly trace your previous code records, you must pay attention to this topic.
If you have used mercurial as a programmer, you may already have an understanding of this rebase concept. Currently, the source control tool most used by programmers is git. A frequent argument in git is whether to use rebase or merge?
To say that the argument is actually not quite accurate. Because in actual work, there are mainly two situations, one is that you don't know rebase at all, and the other is that you don't know how to use rebase at all.
Then let's talk about the difference between rebase and merge. Functionally, rebase will bring your current modification work to the forefront. Your unique modification record order will not change, but the time will be mainly based on the timestamp of the current target branch. Adjustment.
Merge does not change the timestamp. This will cause different people to merge their modified code records, there will be a situation of mutual interlocking. The beginning of this article is a screenshot of the code submission history. The wiring inside is as complicated as a circuit board.
This situation occurs mainly because programmers do not rebase and merge directly.
And such a circuit board-like code submission history is meaningless because it is too complicated. There is almost no readability. If you want to check some historical records, you can easily be quickly submerged in this ocean of information, unable to extricate yourself, and eventually lose yourself and get lost.
2. Git Merge Vs. rebase
Note: Although it has been marked in the reference link, it is necessary to emphasize that the translation of this section refers to the English content of the following link:
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
The purpose of Git merge and rebase is the same, they both merge multiple branches into one. Although their ultimate goal is the same, the two methods are implemented in different ways. So which one should we use?
Here we have a sample repository, which has two different branches: the main branch and the feature branch. We want to blend them together. Let's see how to use these methods to solve this problem.
Picture from https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/fc73a41ce658a6a566e2a54d60534ade/git-flow.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Merge
When you run git merge, your HEAD branch will generate a new commit and retain the ancestors of each commit history.
Picture from
https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/673b91456bdc6fd454c5ad203f825568/git-merge-2.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Fast forward merge is a type of merge that does not create a commit, and will update the branch pointer to the last commit.
Rebase
Rebase is to rewrite the modification of one branch to another branch without creating a new commit.
Every commit you make on the feature branch will create a new commit on the main branch. It looks like these commits have always been written on the master branch.
Picture from https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/5ade4f7276bc6ad18dad4b6078950ac9/git-rebase.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Advantages and disadvantages of Merge
advantage
- Simple to use and easy to understand.
- Keep the original context of the source branch.
- The commits on the source branch are separate from the commits of other branches.
- You can keep the submission history.
Disadvantage
- Chaos
Image from https://storage.kraken.io/kk8yWPxzXVfBD3654oMN/c8b97f4dbb5f7d49fc3eb3624eafff79/london-tube-map-commit.png
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
Pros and cons of Rebase
advantage
- The code history is simplified, linear, and readable.
- Compared with the commit history of many independent feature branches, it is easier to manipulate a single commit history.
- Clean and clear submission information can better track a bug or when a feature was introduced. Can avoid numerous single-line submission of pollution history.
Disadvantage
- The historical submission time will be changed, and the context may be lost.
You need to use Rebase more carefully than Merge.
Should I use Merge or Rebase?
When your team is not familiar with rebase, then git merge is the right choice for you.
- Merge allows to save the commit history of any given function without worrying about overwriting commits and changing the history.
- It can avoid unnecessary git revert or reset.
On the other hand, if you value clean, linear code history more, then git rebase is the most appropriate. This way you can avoid unnecessary submissions, and keep more focused and linear changes!
It should be noted here that if you incorrectly rewrite the history, it may cause serious problems, so make sure you know what you are doing when using Rebase.
3. A glass of water and a bucket of water
Let me talk about the relationship between a glass of water and a bucket of water. This relationship can be used to describe the situation in which teachers impart knowledge to students. The main meaning is that if the teacher gives students a glass of water, the teacher must have a bucket of water.
In fact, this principle is also applicable to our software industry.
Regarding the focus of this article on the code history, what we want to show to the outside is a clear and clean code history. To achieve this goal, we need to do a lot of work. Compared with the clean code history, this work is the relationship between a bucket of water and a glass of water.
This is what we often say, be cruel to yourself and make others more comfortable. Being cruel to yourself is not just empty talk, but actually asking yourself to rack your brains to think about how to do this well? Put yourself on the other side's perspective to see our output. We asked ourselves whether I, as the maintainer and receiver of these codes, can accept such a messy code history. The answer is of course no.
Knowing this, when we are doing code history management, it is worthwhile no matter how hard it is.
Some programmers with many years of work experience may have used many code management tools. One of the operations that these code management tools often use is merge. After entering the git era, these programmers also retained this habit and directly merged.
I talked to some programmers, and they didn't even realize that there was a rebase operation. Some felt that rebase was too troublesome, and gave up after using it a few times.
This is absolutely human nature.
When we are used to doing things in one way, the longer we do it, the safer it feels, because it is effective and can solve problems. When there is another better way, but it is very different from the previous way, we will have instinctive rejection. This is due to our fear of the unknown.
After leaving the comfort zone, most of us will feel uncomfortable, and some will even have a strong sense of loss.
But when we return to our heart, we will find that everything we have given and the pain we endured is worth it. Because our original intention is to satisfy users. The users of code history are programmers like us.
4. How to do rebase correctly?
Important notes:
There are several key points related to Rebase:
- Rebase on your own branch;
- To rebase the correct target branch, note that this target branch is not your remote branch, there are often mistakes in this place;
- Rebase should be done frequently to avoid conflicts or increase the difficulty of conflicts;
- Before incorporating the code, you must do a Rebase and then Merge one last time;
- It is best to use Squash Merge to add the correct commit message;
- Do not rebase on the main branch;
- Try not to force push;
Should rebase on the master branch? How to do rebase?
First of all, I want to emphasize that do not rebase on the main branch. This is because if you do a rebase on the master branch, if you push for the first time, there may be no problem, but if someone else also does a rebase, this will result in two different heads on your master branch. At this time, if you want to push again, there will be a problem.
If everything is controllable, you can force push very roughly. However, if there are more team members, this operation will flush out other submissions that have already come in.
Unless absolutely necessary, we must not rebase on the main branch.
Next, let's talk about a scenario where rebase is used correctly. After receiving a task, we will create a new branch on the latest node commit on the main branch. On the new branch, we will continue to make new commits until the branch task is completed.
At this time, we want to create a merge request or pull request. Before that, the first thing we need to do is rebase. The target branch selected by rebase is our master branch.
After completing this rebase operation, we can create mr or pr. There may be many revisions during the review process. After the revision is completed, you need to
rebase and then push. Repeated this several times, mr or pr approved. At this point, we will do a squash merge to pack several commits into one on the main branch.
The above is a description and explanation of a realistic case of how to use rebase in the normal work process. I hope you can experience it and tell me your experience. Please leave a message and tell me your thoughts.
references
https://dev.to/neshaz/git-merge-vs-git-rebase-5134
https://www.perforce.com/blog/vcs/git-rebase-vs-merge-which-better
https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners
https://git-scm.com/docs/gittutorial
Click to follow and learn about Huawei Cloud's fresh technology for the first time~