Git merges are common operations. Merge or rebase can do the trick, but rebase can merge a commit and make the merge commit represent a small function. This will allow code reviewer to look at the code based on the merged COMMIT, relieving reviewer pressure, and rebase the graph to make it more readable. This paper is divided into two parts. The first part is about a specific development process, using merge and Rebase respectively, comparing graph and COMMIT, and showing the advantages of rebase combining commit and rebase. The second part is a summary of the basic working principle and common commands of Git.
Merge vs rebase
In our work, we choose an appropriate development process, which is conducive to multi-person collaborative development. We recommend the development process shown in the following figure, and the use of MREGE and Rebase is also based on the development process shown in the following figure.
Graph one:
The development process of Figure 1 is briefly described as follows:
(1) Pull the latest trunk branch to local, create their own branch based on the trunk branch;
(2) After the development of your branch, push it to the Git server and propose a PR;
(3) Reviewer accepted PR, merged her branch into the main branch, and concluded this round of development.
1.1. Use Merge
We simulated two students to develop according to the above process. First, create a GitSkills repository on Github. When creating the repository, choose to automatically create the readme. md file, as shown below:
Figure 2:
Create folders A and B locally to simulate the development process of two students respectively, as shown in the picture below:
Figure 3:
In A and B respectively folder execution git clone [email protected]: Lcf2211974 / gitskills git command.
Ok, we are ready to happily simulate the development process of two students.
The following procedures are based on the A/ GitSkills folder:
Create your own branch git checkout -b dev1
Readme. md was modified twice and committed twice;
Push Dev1 to Github with a PR;
Accept PR, on Github, and incorporate Dev1 into the trunk.
The operation is as follows:
Figure 4:
Git log –graph –pretty=oneline –abbrev-commit As shown below:
Fig5.
Yes, if add 1 and Add 2 are small function points, you can merge add 1 and Add 2 into a single commit. Make the commit of the trunk cleaner, which can be done with Rebase, more on that later.
Now that you’ve developed on A/ GITSkills, you’re ready to develop on B/ GitSkills.
The following procedures are based on the B/ GitSkills folder:
Create your own branch git checkout -b dev2;
Readme. md was modified twice and committed twice;
Pull the latest trunk and merge it into the Dev2 branch;
Push Dev2 to Github with a PR;
Accept PR, on Github, and incorporate Dev2 into the trunk.
The operation is as follows:
Figure 6:
Git log –oneline –graph –pretty=oneline –abbrev-commit And graph, as shown below:
Figure 7:
This time, we simulated the development of two students in a round. If many people continue to develop like this, the graph will almost not need to look at it, and the commit of the trunk will become trivial and numerous. It’s hard enough to see how the code behaves based on a commit, so let’s optimize graph with a Rebase and commit to the trunk.
Before we start to optimize graph and commit with rebase, let’s take a look at merge.
Before we merged main into Dev2, the two branches looked like this:
Figure 8:
After merging main into Dev2, the two branches look like this:
Figure 9:
Git log verification in dev2 branch:
Figure 10:
On Dev2, drop commit back to E, and the Dev2 branch looks like this:
Figure 11:
Actual verification:
Figure 12:
Similarly, on Dev2, drop commit back to B, and the Dev2 branch looks like this:
Figure 13:
Merge is a very logical way to merge a branch. If you don’t understand, you can imagine what the branch should look like after merging.
That’s it for merge, let’s rebase.
1.2 use rebase
Same as merge:
The following operations are done under the A/ GitSkills folder:
Git rebase -i main git rebase -i main git rebase -i main git rebase -i main
Git rebase -i main
Figure 14:
Explain the order in Chinese as follows, the Chinese interpretation of teacher Ruan Yifeng’s explanation of the order:
- Pick: Normally selected
- Reword: select and modify the submission information.
- Edit: When selected, rebase is paused, allowing you to modify the commit (see here)
- Squash: If squash is selected, the current COMMIT is merged with the previous COMMIT
- Fixup: similar to a squash, but does not save the commit information of the current commit
- Exec: Executes other shell commands
I used reword command for add 1 commit and fixup command for add 2 commit, save and exit, as shown below:
Figure 15:
Apply the commit command, save, and push it to the page for modifying the comment, as shown in the following image:
Figure 16:
After modifying the comment, save and exit, then use git log to check the commit status of dev1, as shown in the following picture:
Figure 17:
After rebase, we pushed dev1 to Github again, raised a PR, accepted the PR, merged dev1 into the trunk, and switched to the main branch. Take a look at the commit and graph below:
Figure 18:
Merge reduces the number of rebases by 1 commit. Rebase is not implemented yet.
Having completed development on A/ GITSkills, we went on to develop on B/ GitSkills:
The following operations are based on the B/ GitSkills folder:
Git rebase -i main on dev2. Git rebase -i main on dev2. I still choose to use reword command for Add 3 and fixup command for Add 4. After using the command, there is a conflict, so there is no interface for modifying annotations, as shown in the picture below:
Figure 19:
After readme. md has resolved the first conflict, run git add., and then run git rebase –continue. Git add. Git rebase –continue — git rebase –continue — git rebase –continue Now that the rebase operation is complete, let’s look at the commit and graph situation on the Dev2 branch:
Figure 20:
As you can see, dev2’s commit and graph are much cleaner with Rebase than with Merge.
Rebase rebase rebase rebase rebase rebase rebase
Before rebase, the main and dev2 branches looked like this:
Figure 21:
With Rebase, the main and dev2 branches look like this:
Figure 22:
In rebase, we compare the fork points of Dev2 and main, A is the fork point, save D and E, apply B and C to Dev2, and then D is the change based on C, we add E to D incidentally, because D is the change based on C, So when main joins dev2, it does not produce a merge COMMIT.
Now that we understand how rebase merges and rebases, we go through the rest of the process, push the rebase dev2 branch to Github, raise a PR, accept the PR, merge Dev2 into the trunk, pull down the latest trunk, and look at Commit and Graph. As shown below:
Figure 23:
As you can see, the commit is based on function points, and the graph is very readable. If everyone on the team follows the above process, the graph will continue as shown above. The Commit is based on function points, and we can see how the code iterates by reading the Commit.
Git basic principle and common command summary, as well as summary, etc.