3 moves to get it done! Keep a clean Git commit record

This article brings you knowledge about keeping clean Git commit records, including "git commit –amend", "git rebase -i" and "rebase" Question, hope it helps everyone.

## Recommended study: "

Git Tutorial"

Everyone has learned how to write code in a standardized and concise way

, but rarely learn how to standardize and concise submit code. Nowadays, everyone basically uses Git as a source code management tool. Git provides great flexibility. We submit/merge code according to various workflows. If this flexibility is not well controlled, it will also cause many problems

The most common problem is the messy git log history. It is really an old lady's foot wrap, smelly and long. I personally dislike this kind of log

The root cause of this problem is submitting code at will.

The code has been submitted, is there any way to save it? Three tips can solve the problem perfectly

Make good use of git commit –amend

The help document of this command is described like this:

--amend               amend previous commit

In other words, it It can help us modify

The last submission

can modify not only the message we submitted, but also the file we submitted, and finally replace the last commit-id

We may miss a certain file during a certain submission. When we submit again, there may be a useless commit-id. If everyone does this, the git log will gradually become too messy to track the complete function

Suppose we have such a piece of log information

* 98a75af (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2
* 119f86e feat: [JIRA123] add feature 1.1
* 5dd0ad3 feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

Suppose we want to modify the last log message, we can use the following command:

git commit --amend -m "feat: [JIRA123] add feature 1.2 and 1.3"

Let’s take a look at the log information again, we can find , we replaced the old commit-id 98a75af with the new commit-id 5e354d1, modified the message, and did not add nodes

* 5e354d1 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2 and 1.3
* 119f86e feat: [JIRA123] add feature 1.1
* 5dd0ad3 feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

Now the files in our repo look like this:

.
├── README.md
└── feat1.txt

0 directories, 2 files

Suppose that when we submitted feature 1.3, we forgot a configuration file config.yaml and did not want to modify the log or add a new commit-id. Then the following command is very easy to use

echo "feature 1.3 config info" > config.yaml
git add .
git commit --amend --no-edit

git commit -- amend --no-edit is the soul. Let’s take a look at the current repo file:

.
├── README.md
├── config.yaml
└── feat1.txt

0 directories, 3 files

Let’s take a look at git log

* 247572e (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2 and 1.3
* 119f86e feat: [JIRA123] add feature 1.1
* 5dd0ad3 feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

Knowing this technique, we can ensure that every submission we make All contain valid information. A picture describing the process looks like this:

With the buff bonus of --no-edit, it is more powerful

Make good use of it git rebase -i

You can see that the above logs are all in the development of feature1. Before merging the feature branch into the main branch, we should continue to merge the log commit nodes. This is used

git rebase -i HEAD~n

where n represents the last few submissions. We have three submissions for feature 1 above, so we can use:

git rebase -i HEAD~3

After running, a vim editor will be displayed with the following content:

 1 pick 5dd0ad3 feat: [JIRA123] add feature 1
 2 pick 119f86e feat: [JIRA123] add feature 1.1
 3 pick 247572e feat: [JIRA123] add feature 1.2 and 1.3
 4
 5 # Rebase c69f53d..247572e onto c69f53d (3 commands)
 6 #
 7 # Commands:
 8 # p, pick <commit> = use commit
 9 # r, reword <commit> = use commit, but edit the commit message
10 # e, edit <commit> = use commit, but stop for amending
11 # s, squash <commit> = use commit, but meld into previous commit
12 # f, fixup <commit> = like "squash", but discard this commit's log message
13 # x, exec <command> = run command (the rest of the line) using shell
14 # d, drop <commit> = remove commit
15 # l, label <label> = label current HEAD with a name
16 # t, reset <label> = reset HEAD to a label
17 # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
18 # .       create a merge commit using the original merge commit's
19 # .       message (or the oneline, if no original merge commit was
20 # .       specified). Use -c <commit> to reword the commit message.
21 #
22 # These lines can be re-ordered; they are executed from top to bottom.
23 #
24 # If you remove a line here THAT COMMIT WILL BE LOST.
25 #
26 #   However, if you remove everything, the rebase will be aborted.
27 #
28 #
29 # Note that empty commits are commented out</commit></oneline></label></commit></commit></label></label></commit></command></commit></commit></commit></commit></commit>

The most commonly used methods for merging commit-ids are squash and fixup. The former contains commit message, while the latter does not. Use fixup here, and then :wq to exit

1 pick 5dd0ad3 feat: [JIRA123] add feature 1
2 fixup 119f86e feat: [JIRA123] add feature 1.1
3 fixup 247572e feat: [JIRA123] add feature 1.2 and 1.3

Let’s take a look at the log again, it’s very clear

* 41cd711 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

Make good use of rebase

The above feature1 has been completely developed, and the main branch has also been updated by others. Then merge the feature back to the main branch to prevent code conflicts. You need to merge the contents of the main branch into the feature first. If you use the merge command, there will be an extra merge node, and there will also be an inflection point in the log history, which is not linear, so here we can use the rebase command on the feature branch

git pull origin main --rebase

The pull command automatically helps us merge, but here in the form of rebase, let’s take a look at the log

* d40daa6 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1
* 446f463 (origin/main, origin/HEAD) Create main.properties
* c69f53d (origin/feature/JIRA123-amend-test, main) Initial commit

our feature1 function on The submission node of the top of main still remains linear. Next, you can push the code, then submit a PR, and merge your feature to the main branch.

A brief description of the difference between merge and rebase is this:

I use git pull origin main --rebase here to omit the process of switching main and pulling the latest content and then switching back. It is done in one step. The principles behind it are all shown in the picture above.

Using rebase is There is a golden rule that must be followed. This has been said before, so I won’t go into details.

Summary

With these three tips, I believe everyone’s git log will be extremely clear. If you don’t know it yet, you can definitely use it. If your group members don’t know it, you can definitely promote it. This kind of repo will look healthier.

Recommended study: "Git Tutorial》

The above is the detailed content of 3 moves to get it done! Keep a clean Git commit record. For more information, please follow other related articles on the PHP Chinese website!