I'm not in a good state recently, and I haven't written technical articles. Today, I climbed up and chatted with everyone about GIT's rebase mode (rebase).
This article is based on a certain GIT foundation. If you haven't touched it before, you can read the two introductory articles written before.
Animation: Literacy Git Version Control (Part 1)
Animation: Literacy Git Version Control (Part 2)
The first time I used and learned the rebasing model in a teamwork project was taught me by the boss like a textbook. Through continuous use in the project, I summarized some of my own use and views.
GIT itself is not so good for some beginners. For me personally, at the beginning, some basic concepts were not transparently understood when they were first contacted. Only when these concepts were put into practice to form their own understanding, Know that this concept originally meant this and what this command looks like.
Therefore, Xiaolu draws as many pictures as possible, and less nonsense, so that friends who do not have a thorough understanding of GIT can provide some help.
1. What is rebase?
Rebase, we can understand the meaning of low base. Just like building a building, layer by layer is built up, and the bottom is the foundation. We call each layer of the building the foundation.
(For a better understanding, take the above-mentioned building as an example)
Suppose, our floor is built, there are 18 floors in total, and multiple decorators are needed to decorate each floor. There are three people in my decoration team, namely A, B, and C.
A is in charge of the first layer, B is in charge of the second layer, and C is in charge of the third layer. According to normal logic, whoever has finished decorating his own floor in advance of the three people will go to the fourth floor to decorate.
But there is a problem. If the second floor of B is also decorated, but B does not know the latest progress of the other two people, so he needs to update his current progress to the latest in some way (B should know the next step of the decoration Several floors) in order to continue to decorate based on the progress of the other two.
Although the above example of building a building is not very suitable for teamwork in the project to use GIT to rebase, in order to give everyone a general impression.
2. Why use rebasing?
Generally, we use GIT version control in team cooperation. Each person develops on his own branch. Finally, the person in charge merges the branch developed by each person to the main branch. There is a rebasing model. What is it? ?
First, the project has become bigger, the team has more people, and more and more branches are submitted, and everyone has to be merged into the master branch after committing. The entire git branch diagram looks bad, not conducive to maintenance and management. (As shown in FIG)
Second, the project is full of various commits. If there is an emergency one day, the code needs to be rolled back, and the large number of commits need to be looked at one by one, so that you can see doubtful life.
The above two reasons can completely make me give up the traditional submission and merging, and the code submitted in the rebase mode is very clear. (As shown below)
3. How to rebase?
For how to rebase, the most important thing in this part is to practice, practice, and practice. There is no practice, you can read it for nothing, remember what I said.
In the rebase mode, the following commonly used commands are used, and the above-mentioned building is taken as an example.
When the second layer of B is finished, it wants to know the development progress of everyone below, and then proceed with the next development based on everyone's progress.
Just like in the project, I want to submit the function that I have developed, but when I develop the current function, someone in the remote warehouse may have already submitted the code, causing the code in my local warehouse and the remote warehouse to be inconsistent.
To achieve consistency with the remote warehouse code before the push code, we need to rebase (rebase), the command is as follows:
1git pull base dev --rebase
This order is equivalent to that B went directly to the fifth floor of the floor for decoration. And our decoration record, that is, our main development branch, has become very clear and clear, which is a branch line full of commits.
4. I have broken the base
But here comes the problem. When I first used the GIT rebase mode, I played it many times and I got some experience.
When I submit the latest code every time, I forget to rebase every time, that is, every time I don’t take into account the latest remote code, I develop the function and submit it directly, causing the online code to fork (in fact, it’s back to Original submission method) .
Very anxious, what should I do? The eldest son goes out, one is the best, nothing wrong.
Use rollback and pick methods to prevent the main branch from diverging. The so-called pick is to use the cherry-pick command to reattach the commit to the branch you want to mount.
1git cherry-pick <commit id>
When you have finished picking, perform push and pr again, and the forked branch will return to the original line. Isn't it nice?
summary
After I fully understand the Git rebase, it doesn't feel particularly difficult, but I just came into contact with it in the early stage, and there are indeed many things that I don't understand, which leads to broken games many times. Having said that, how can you see a rainbow without experiencing wind and rain?