DevUI is a team with both design and engineering perspectives, serving huawei DevCloud platform and huawei internal background systems, as well as designers and front-end engineers. Official website: Devui.Design Ng Component library: Ng-Devui (welcome Star) official exchange: Added Devui-Official
The introduction
I’ve been working with Git for about three years in multi-party collaborative development, and in most cases I can count the git commands with a little more than one hand
git add, git commit, git push, git merge, git pull, git log
In theory, as long as the project branch is properly managed, these few commands should be sufficient for all the daily development work. But if we look at our Git Graph once in a while, oh my God, what a mess.
Given the chaos of branch management (or lack of branch management at all), we often encounter unexpected problems that require a variety of native Git commands to solve our problems, such as git Rebase in this article.
Git rebase and Git Merge
Git rebase changes the base of a commit record. Git rebase = git merge Git rebase = git merge git rebase = git merge
If you think back to our daily workflow, imagine a and B working together on three branches: Develop, develop_A, and develop_B. Two people working on a develop_A and develop_B branch on a daily basis, and then phasing in to Develop, the likely workflow from a’s point of view might look like this:
(1) Personally develop your own features on the develop_A branch
(2) During this time, others may be adding new features to Develop
(3) After personal function development, merge functions developed by others by means of merge
Figure 1. Daily Merge workflow
Git operation commands corresponding to Figure 1 are as follows:
Git Checkout develop_a git pull origin develop = git fetch origin develop + git merge developCopy the codeIf we use Git rebase to implement the same workflow, the result is as follows:
Figure 2 Before Git Rebase
Figure 3 git Rebase
Figure 4 after Git rebase
Figure 2-4 Git operation commands are as follows:
Git Checkout develop_a git fetch origin develop git rebase develop git checkout develop git merge develop_a git br -d develop_aCopy the codeGit merge git rebase git merge
(1) Both can be used for native code merging
Git merge keeps a record of real user commits and generates a new commit when it merges
Git rebase will rewrite the historical commit record. This rewriting is not limited to the structure of the tree, but also the commit ID of the nodes in the tree. Therefore, e’ is used to represent E ‘of Figure 2 in Figure 3 and Figure 4
How to use Git rebase -i to modify historical commit records
Git rebase – I This means that user interaction can be incorporated into the rebasing process, through which we can actively rewrite the history of the commit, including modifications, merges, and deletes. To modify the historical commit record, let’s use the commit record obtained with Rebase above as an example. Before the change, the commit record looked like this.
Git rebase -i: Git rebase -i: Git rebase -i
(1) List a range of submitted records and indicate which records you need to modify within this range
(2) Perform the above modifications again, and resolve conflicts if encountered
(3) Complete the rebase operation
Take the commit record in the screenshot above as an example to modify the historical commit MSG as follows:
Git rebase -i HEAD~6 git rebase -i HEAD~6Copy the code
After executing the above command, a file is opened in vim mode, showing the last six commits, 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 changing the pick in front of each line to R, S and D respectively. First, we try to modify the submission information by changing the pick in front of the second row to R, save and exit. When the current page closes, a new page opens, allowing you to edit the selected submission information.
After editing the information, save and exit, and you are done modifying the historical commit record. The develop_A commit record is feat_c, but the develop branch’s commit record is feat_UPDATE. One thing to note here is that the commit ID for the same commit has changed on the Develop and develop_A branches, which will be mentioned again later.
Git reset –soft HEAD^ In addition to changing the commit MSG, you can also modify the level commit by changing pick to E and git reset –soft HEAD^.
The procedure for merging and deleting historical submissions is similar to that for editing. You only need to change Pick to S and D, respectively. If you encounter a conflict during rebase, resolve it manually and use git rebase –continue to complete the rebase operation. Git Rebase’s prompt is very friendly and tells you what you need to do to solve the current problem.
What are the rules you must follow to use Git rebase -i?
Interactive rebasing is a very powerful feature in terms of the ability to modify the historical submission record. However, there is a hard rule to follow when using this feature: do not base the online branch submission record!
Git git guide:
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 I talk about why you can’t do interactive rebasing for online commits, let me explain what you can do if you want to do this for online functionality.
Git push -f is used to override the remote branch. If you do not override the remote branch, the new push and remote merge will make your local rebase meaningless. As we mentioned above, the commit ID of all nodes changes from the base node onwards.
For the same reason, even if you use git push – f the rebase in the remote branch, if your colleagues you perform rebase operation still exist in the development branch (either modify, merge, or delete) against those branches, so when your colleague after the merge your submission, you all want to use rebase change back!
How to fix git rebase-i if you break git rebase-i rules
Here we try to illustrate the results of online commit execution base change and how to avoid this result by way of bullet points:
(1) You rebase part of the online commit locally. This part of the commit is called A, and the COMMIT ID of A changes after rebasing
(2) The commit you changed locally may exist in your colleague’s development branch, which we call B. They have the same content as A, but a different COMMIT ID
(3) If you forcibly push the base change result to the remote repository, your colleague will cause a and B to merge when executing git pull locally, and both will appear in the historical submission, so your base change behavior is invalid
(4) What we want is for your colleague to skip the merge of A and B when he pulls code online, and just merge the changes added to his local branch
So with all that said, the final conclusion is, use a change of basis to solve the change of base band problem. That is, your colleague uses Git rebase to rebase his local changes to the branch where you performed remote rebase.
In short, your colleague uses Git pull –rebase instead of Git pull to pull remote branches. During this operation, Git checks the information we mentioned above and incorporates changes that are truly local to the peer at the end of the remote branch.
The text description may be a little weak, but for more information, you can find it here: git-scm.com/book/zh/v2/…
So how do we use Git rebase
In view of the problems with git rebase described above, the final question to answer is how you should use git rebase in your daily work.
As a general rule, only base clean history for local changes that have not been pushed or shared with others, and never base commits that have been pushed elsewhere, so that you can take advantage of both methods (rebase and merge).
Join us
We are DevUI team, welcome to come here and build elegant and efficient human-computer design/research and development system with us. Email: [email protected].
The text/DevUI east less
Previous articles are recommended
How to use quadrant components by Hand
Dark Mode and Thematic Development of Web Interfaces
“How to build a grayscale Publishing environment”