The monkey is responsible for maintaining a clean Git submission record, three tips for you

background

Everyone has learned how to standardize and concise write code , but seldom learn how to standardize and concise submit code . Now everyone basically uses Git as a source code management tool. Git provides great flexibility. We submit/merge code according to various workflows. This flexibility is not well controlled, and it will also cause many problems.

The most common problem is the mess of git log history, which is really old lady’s footwear, smelly and long, and personally dislike this kind of log.

The root cause of this problem is to submit code at will.

The code is submitted, is there any way to save it? Three tips can be solved perfectly

Make good use of git commit --amend

The help document for this command describes it like this:

--amend               amend previous commit

In other words, it can help us modify last commit

You can modify the message we submitted, you can modify the file we submitted, and finally replace the last commit-id

We may miss a certain file in a certain submission. When we submit again, there may be a useless commit-id. Everyone does this. The git log will gradually become chaotic and unable 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 that we 5e354d1 with the new commit-id 98a75af , 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

The file in our repo now looks like this:

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

0 directories, 2 files

Suppose we forgot a configuration file config.yaml feature 1.3 , 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 where the soul is. Take a look at the current repo file:

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

0 directories, 3 files

Let's look at git log again

* 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 can ensure that each of our submissions contains valid information. A picture describing this process looks like this:

With --no-edit , it is more powerful

Make good use of git rebase -i

As you can see, the above logs are all developing feature1. Before we merge the feature branch to the main branch, we should continue to merge log commit nodes, which is used

git rebase -i HEAD~n

Among them, n represents the last few submissions. Above we have three submissions for feature 1, so you 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

The most commonly used to merge commit-id are squash and fixup . The former contains commit message, while the latter does not. Fixup is used here, and :wq exits

  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 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 feature1 above has been fully developed, and the main branch has been updated by others. Before the feature merge back to the main branch, in case of code conflicts, you need to merge the content of the main branch into the feature first. If you use the merge command, There will be one more merge node, and there will be inflection points 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

Behind the pull command is to automatically merge for us, but here in the form of rebase, 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

The commit node of our feature1 function on top of main is still linear. Then you can push the code, then mention the PR, and merge your feature to the main branch.

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

I use git pull origin main --rebase here to omit the process of switching main and pull the latest content and then switch back. It is in place in one step, and the principle behind it is shown in the figure above.

There is a golden rule to use rebase. I have said this before, so I won’t repeat it.

Summarize

With these three tips, I believe that everyone’s git log is very clear. If you don’t know it, you can use it. If your group members don’t know, you can promote it. Such a repo looks just like healthier

Next, I will introduce a guide for multi-branch switching that does not affect each other.

Ri Gong Yibing｜ Original