Devui is a team with both design and engineering perspectives. It serves the devcloud platform of Huawei cloud and several middle and background systems within Huawei, as well as designers and front-end engineers.
Official website: devui.design
Ng component library: ng devui (welcome star)
Official communication group: add devui assistant (wechat: devui official) to the group
It takes about three years to use git to participate in the cooperative development between multiple people. In most scenarios, GIT commands can be counted with a little more than one hand
git add, git commit, git push, git merge, git pull, git log
Theoretically, as long as the project branch can be managed reasonably, these commands are enough to cope with all the daily development work. But if we occasionally look at our git graph, my God, why is it so messy.
In view of the confusion of branch management (or no branch management at all), we often encounter some unexpected problems. Therefore, we need to use many familiar git commands to solve our problems, such as git rebase mentioned in this article.
Git rebase and git merge
The Chinese name of GIT rebase is base change, which is to change the base for submitting records once. In this link, we might as well take this assumption: git rebase ≈ git merge, and use two commands to implement the same workflow to compare the similarities and differences between them.
Think back to our daily workflow. Suppose a and B work together to develop three branches: develop and develop_ a, develop_ b。 Two people are in development_ A and development_ Daily development is carried out on branch B and phased integration into development. From the perspective of a, the possible workflow is as follows:
(1) Personal development_ Develop your own functions on the a branch
(2) During this time, others may continue to incorporate new features into developep
(3) After the development of personal functions, integrate the functions developed by others through merge
Figure 1 daily merge workflow
The GIT operation commands corresponding to figure 1 are as follows:
git checkout develop_a //Local feature development git pull origin develop = git fetch origin develop + git merge develop
After completing such a workflow, if we use git rebase to implement it, the results are as follows:
Figure 2 before git rebase
Figure 3 in Git rebase
Figure 4 after git rebase
The GIT operation commands corresponding to figure 2-4 are as follows:
git checkout develop_a //Local feature development git fetch origin develop git rebase develop git checkout develop git merge develop_a git br -d develop_a
Thus, the similarities and differences between git rebase and git merge are as follows:
(1) Both can be used for native code merging
(2) Git merge keeps true user submission records, andA new commit will be generated at merge
(3) Git rebase will rewrite the historical submission record. The rewriting here is not limited to the tree structure, and the commit ID of the node on the tree will not be rewritten. Therefore, e ‘in Figure 3 and Figure 4 represents e’ in Figure 2, which can ensure that the submission record is very refreshing
How to use git rebase – I to modify historical submission records
Git rebase – I, the Chinese name is interactive variable base. It means that it is possible to change the baseIncorporate user interactionYes, through the interactive process, we can actively rewrite the historical submission records, including modification, merging and deletion. We take the submission record obtained after using rebase as an example to modify the historical submission record. Before modification, the submission record looks like this.
The process of modifying history submission using git rebase – I mainly includes three steps:
(1) List a scope for submitting records and indicate which records you need to modify within this scope
(2) To perform the above modifications once. If conflicts are encountered, they need to be resolved
(3) Rebase operation completed
Take the submission record in the screenshot above as an example to modify the historical commit MSG. The operation steps are as follows:
//View the last 6 submitted records and select which record to modify git rebase -i HEAD~6
After executing the above command, a file will be opened in VIM mode. The last 6 submissions are displayed in the file, from top to bottom and from far to near.
As can be seen from the following comments, we can modify, merge and delete the history records by modifying the pick in front of each line to R, s and D. First, we try to modify the submission information, change the pick in front of the second line to R, save and exit. When the current page is closed, a new page will be opened to allow you to edit the selected submission information.
After editing the information, save and exit to complete the modification of the historical submission record. By looking at the figure below, you can find that development_ The commit MSG in a’s submission record is still feat_ c. However, the corresponding commit record in the development branch, commit MSG, has become feat: c-update. One phenomenon to note here isDevelopep and developep_ The commit ID of the same Submission on the a branch has changed, this will be mentioned again later.
In addition to modifying the commit MSG submitted, we can also change the pick to e to combine
git reset --soft HEAD^Modify the changes submitted by grade.
The operation steps of merging and deleting history submission are similar to editing. You only need to change the pick to s and D respectively. You can try it yourself. If conflicts are encountered during rebase, they need to be resolved manually and then used
git rebase --continueRebase operation completed. The prompt of GIT rebase is still very friendly. It will tell you what you need to do to solve the current problem.
What are the rules that must be followed to use git rebase – I?
From the function of modifying history submission records, interactive base change is a very powerful function. However, to use this function, you must follow an iron rule:Do not rebase the submission records of online branches!
To quote git’s official guidance document, it is roughly as follows:
If you follow this golden rule, nothing will go wrong. Otherwise, the people will hate you, and your friends and family will laugh at you and spit on you.
Before talking about why interactive rebasing cannot be performed on online submissions, let’s talk about what to do if you want to perform this operation on online functions.
First, you need to base successfully in your own place, and then use
git push -fForcibly push and overwrite the remote corresponding branch. The reason why you need to perform overlay push is that if you do not overwrite, the new submission generated after the current base change will be merged with the remote, resulting in the meaningless local base change behavior. As we mentioned above, the commit ID of all nodes will change from the base node.
The same reason, even if you use
git push -fThe remote branch has changed base. If your colleague’s development branch still has the branches that you execute when changing base operations (whether modified, merged or deleted), then all of you want to change the base changes after your colleague merge submits.
If you break the usage rule of GIT rebase – I, how should you remedy it
Here, we try to explain the results of online submission and implementation of base change and how to avoid this result by means of key points:
(1) You have rebased some online submissions locally, which we call A. After rebasing, the commit ID of a changes
(2) These submissions you change locally may exist in your colleague’s development branch, which we call B. they have the same content as a and different commit ID
(3) If you forcibly push the base change results to the remote warehouse, your colleagues will merge a and B when they execute git pull locally, and both appear in the history submission, resulting in the invalidation of your base change behavior
(4) What we want is for your colleague to skip the merging of a and B when pulling the online code, and just merge the new modifications on his local branch
After talking so much, the final conclusion is to use variable basis to solve the problems caused by variable basis. That is, your colleague uses git rebase to rebase his local modification to the remote rebase branch.
In short, it is used by your colleagues
git pull --rebaseinstead of
git pullTo pull the remote branch. In the process of this operation, GIT will check the information of several key points mentioned above and incorporate the real local modifications of colleagues into the last part of the remote branch.
The text description may be weak. For more details, please refer to here: https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF -%E5%8F%98%E5%9F%BA
So how should we use git rebase
In view of the possible problems caused by git rebase described above, the last question to be answered is how we should use git rebase in our daily work. Similarly, borrow a sentence from the official git document:
The general principle is to clean up the history only for local modifications that have not been pushed or shared with others, and never for submissions that have been pushed elsewhere. In this way, you can enjoy the convenience of the two methods (rebase and merge).
We are the devui team. Welcome to join us to build an elegant and efficient man-machine design / R & D system. Recruitment email: [email protected] 。
Text / devui Shaodong
Previous articles recommended
Teach you how to use quadrant chart components by hand
Web interface patterns and thematic development
Teach you how to build a gray publishing environment