background

We all learn how to write code cleanly, but we rarely learn how to commit code cleanly. Git is now used as a source management tool. Git provides great flexibility. We submit/merge code according to various workflows

The most common problem is a jumbled git log history, which is really an old lady’s foot-log. I hate this type of log

The root cause of this problem is arbitrary code submission.

Is there any way to save the code once it’s committed? Three tips, and that’s the perfect solution

Make an amend

The help documentation for this command describes it as follows:

--amend               amend previous commit
Copy the code

That is, it helps us modify the last commit

We can modify both the message we commit and the file we commit, and finally replace the last commit-ID

We might miss a file in one commit, and when we commit again, we might have a useless commit-ID, and everyone does this, and the Git log will become too messy to keep track of the full functionality

So let’s say we have a log that looks like this

* 98a75AF (HEAD -> feature/ amend-test) feat: [amend-test] [JIRA123] Add Feature 1 * 5dd0ad3 feat: [JIRA123] add feature 1 * c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commitCopy the code

Assuming 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"Copy the code

We have replaced the old commit-id 98a75AF with the new commit-id 5e354D1, and changed the message without adding nodes

* 5e354D1 (HEAD -> feature/ jira123-amend-test) feat: [JIRA123] Add feature 1.2 and 1.3 * 119f86e feat: [JIRA123] Add Feature 1 * 5dd0ad3 feat: [JIRA123] add feature 1 * c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commitCopy the code

Now our repO file looks like this:

.├ ── 1.txt 0 directories, 2 filesCopy the code

The following command is useful if we forget the config. Yaml configuration file when submitting feature 1.3 and do not want to modify the log and add a new commit-id

Echo "feature 1.3 config info" > config.yaml git add. git commit --amend --no-editCopy the code

Git commit –amend –no-edit is where the soul resides, and look at the current repo file:

.├ ── ├─ config.├ ─ 1.txt 0 directories, 3 filesCopy the code

Git logs

* 247572E (HEAD -> feature/ amend-test) feat: [JIRA123] Add feature 1.2 and 1.3 * 129f86e feat: [JIRA123] Add Feature 1 * 5dd0ad3 feat: [JIRA123] add feature 1 * c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commitCopy the code

Knowing this technique ensures that every commit we make contains valid information. A picture of the process looks like this:

With the — No-Edit buff bonus, it’s a little more powerful

Git rebase-i

As you can see, the logs above are all in feature1 development. We should merge the feature branch into the main branch and continue to merge the log commit node

git rebase -i HEAD~n
Copy the code

Where, n represents the last few submissions. We have three submissions for feature 1 above, so it can be used:

git rebase -i HEAD~3
Copy the code

When you run it, a Vim editor is 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
Copy the code

The most common ways to merge commit- ids are squash and fixup. The former contains a commit message and the latter does not

1 Pick 5DD0ad3 feat: [JIRA123] Add Feature 12 Fixup 119f86e feat: [JIRA123] Add Feature 23 Fixup 247572E feat: [JIRA123] Add feature 1.2 and 1.3Copy the code

If we 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
Copy the code

Use rebase

Feature1 has been fully developed, and other updates have been made to the main branch. Before merging the feature into the main branch, you need to merge the main branch into the feature to prevent code conflicts. There will be a merge node and an inflection point will appear in the log history, which is not linear, so we can use the rebase command on the feature branch here

git pull origin main --rebase
Copy the code

The pull command is the one that automatically merges us, but in the form of rebase, let’s 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
Copy the code

Our Feature1 feature works on top of the main submission nodes, and remains linear. Now you can push your code and PR to merge your feature into the main branch

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

Here, I use Git pull Origin main –rebase to omit the process of switching from main to pull the latest content and then cutting back. The principle behind this is shown in the figure above

There is a golden rule to follow when using Rebase, which has been mentioned before and won’t be repeated here

conclusion

With these three tips, I believe everyone’s Git log is very clear, if you don’t know, you can use it, if your group members don’t know, you can promote it, so that the repO looks healthier

Next, we will introduce a multi-branch switch without affecting each other’s personal blog: https://dayarch.top

Day arch a soldier | original