Git merge Git merge git merge Git merge This makes it very easy for us to do collaborative development, where everyone develops code in their own branch and then merges it into the Master branch. This way you can ensure that your code doesn’t get messy, but there is an implicit drawback.

When merging two branches that have no upstream or downstream relationship, Git automatically generates a merge commit for us, which records the merge. There is nothing wrong with merging. The problem is that if you have a special case where you need to merge again and again, the commit record will be very messy and you will not know what is what. Especially if you merge a branch with a huge change, your Git log is almost completely unreadable and will be filled with other people’s messy commit records that you don’t understand.

To solve this headache, we need to use the Rebase operation.

Rebase profile

Rebase is a very powerful operation that can do some amazing things, but it can also be dangerous because if used badly it can cause huge problems for your team’s code and become the villain of the pack. So we must first understand the principle before using it, and then carefully use it, otherwise it is likely to cause problems.

Let’s start with the function of Rebase. The function of Rebase is to extract the changes we made in branch A and apply them to the code of branch B, which is like A patch. I’m being very inane here, but I pulled some images from Learngitbranching.js.org to make it a little clearer. I also recommend this site, which has some graphical demonstrations and practical functions where we can practice the git commands we have learned. However, it also has a disadvantage that some details are not introduced, which is why I did not recommend it to you at the beginning.


This is a classic image, and it’s the norm in many scenarios. C1 is the online version, and we found a bug when C1 code went online, so we checked out a branch called bugFix. At the same time, there are new functions being developed, which are submitted to the master to form node C2. We can merge the master in the bugFix branch, which is fine, but we can also rebase the master. After rebase the whole git tree looks like this:


The result is as if we went to C2 and then checked out of the bugFix branch and rewrote the code we had written in the bugFix branch. This operation is called rebasing, and when we rebase and submit the merge request, our merge record will be very clean and there will be no additional information about the merge. This is great for scenarios where multiple people are co-developing.

An even better example

The above is just a basic application of the Rebase operation, through which we can implement even more cool features. Let’s look at a submission diagram like this:


This diagram is also very classic. The master is the normal online branch, and the code comes online at C2. After the launch, I continued to develop new requirements. I checked out a new branch feature, and at the same time, THE master underwent some merging and merged some other changes to C4 node. Later, the development of the new branch feature completed an important performance improvement change, C5. At this time, we found a bug in the online code and the performance was not good, we needed to fix it urgently. We checked out the new bugFix branch at C5. We fixed the bug in the bugFix branch and wanted to launch.

At this time, the feature branch continues to be developed to the C6 node, which is still not completed and has not been tested by the system. So we don’t want C6 code to go live, we want C5, C7 and C8 to merge into the master code. We just need to commit after the bugFix branch rebase to master and fix the collision. So once we’re done, we’re going to checkout to master and merge the bugFix branch. The whole process is as follows:

git checkout bugFix
git rebase master
git checkout master
git merge bugFix
Copy the code

We end up with something like this:


We continue to ask the question, what if we only need to merge the bugFix branch’s own changes and do not want to merge the C5 node? If we don’t use Rebase it will be very troublesome and difficult for us to deal with. With Rebase it’s very simple, we just need to use the onto parameter, which limits where we rebase from.

For example, if we want the rebase content to be in the bugFix branch and not in the feature branch, we can write:

git rebase --onto master feature bugFix
Copy the code

Git will first find the common ancestor of the feature and bugFix, and then rebase the part after the common ancestor to the master.

The other problem is that if we were to merge two branches into the master, we would have trouble rebase merging twice, so we could do that as well. Git rebase master merge git rebase master merge git rebase master merge git rebase master merge And then we’ll merge from checkout to master. That is to say, we can write out the execution branch and the target branch in the command, so that we can reach the target branch in one step.

For example, if I am in the master branch and I execute git rebase master bugFix, it will look like this:


It’s a lot easier than writing our own commands one by one.

conclusion

To summarize, we use the rebase command to benefit from smoothing the merge operation and reducing the number of meaningless commit records. It can also implement some trickier functions, but for beginners, this function is still relatively strange, always feel dizzy do not know what they have done. This is perfectly normal, and we can try it out on learngit, where submissions are fake and there are no problems with it, rather than in the real world with real code.

In the next article, we’ll take a look at what Git Rebase can’t do and what the pitfalls are.

That’s all for today’s article. I sincerely wish you all a fruitful day. If you still like today’s content, please join us in a three-way support.

Original link, ask a concern

This article is formatted using MDNICE