关于java:猿猿有责维持整洁的-Git-提交记录三个锦囊送给你

背景

大家都有学习如何标准简洁的 编写代码 ，但却很少学习如何标准简洁的 提交代码。当初大家基本上都用 Git 作为源码治理的工具，Git 提供了极大的灵活性，咱们依照各种 workflow 来提交 / 合并 code，这种灵活性把控不好，也会带来很多问题

最常见的问题就是乱成一团的 git log history，那真的是老太太的裹脚布, 又臭又长, 集体极其不喜爱这种 log

造成这个问题的根本原因就是随便提交代码。

代码都提交了，那还有什么方法援救吗？三个锦囊，就能够完满解决了

善用 git commit –amend

这个命令的帮忙文档是这样形容的：

--amend               amend previous commit

也就是说，它能够帮忙咱们批改 最初一次提交

既能够批改咱们提交的 message，又能够批改咱们提交的文件，最初还会替换最初一个 commit-id

咱们可能会在某次提交的时候脱漏了某个文件，当咱们再次提交就可能会多处一个无用的 commit-id，大家都这样做，git log 缓缓就会乱的无奈追踪残缺性能了

假如咱们有这样一段 log 信息

* 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

假如咱们要批改最初一个 log message，就能够应用上面命令：

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

咱们再来看一下 log 信息, 能够发现，咱们用新的 commit-id 5e354d1 替换了旧的 commit-id 98a75af, 批改了 message，并没有减少节点

* 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

当初咱们的 repo 中文件是这样的：

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

0 directories, 2 files

假如咱们提交 feature 1.3 的时候，遗记了一个配置文件 config.yaml, 不想批改 log，不想增加新的 commit-id，那上面的这个命令就十分好用了

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

git commit --amend --no-edit 就是灵魂所在了，来看一下以后的 repo 文件：

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

0 directories, 3 files

再来看一下 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

晓得这个技巧，就能够确保咱们的每次提交都蕴含无效的信息了。一张图形容这个过程就是这个样子了：

有了 --no-edit 的 buff 加成，威力更大一些

善用 git rebase -i

能够看着，下面的 log 都是在开发 feature1，咱们在把 feature 分支 merge 到 main 分支之前，还是应该持续合并 log commit 节点的，这就用到了

git rebase -i HEAD~n

其中 n 代表最初几个提交，下面咱们针对 feature 1 有三个提交，所以就能够应用：

git rebase -i HEAD~3

运行后，会显示一个 vim 编辑器，内容如下：

  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-id 最罕用的是 squash 和 fixup, 前者蕴含 commit message，后者不蕴含，这里应用 fixup, 而后 :wq 退出

  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

咱们再来看一下 log, 这就十分清晰了

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

善用 rebase

下面的 feature1 曾经残缺的开发完了，main 分支也有了其他人的更新，在将 feature merge 回 main 分支之前，以防代码有抵触，须要先将 main 分支的内容合并到 feature 中，如果用 merge 命令，就会多处一个 merge 节点，log history 中也会呈现拐点，并不是线性的，所以这里咱们能够在 feature 分支上应用 rebase 命令

git pull origin main --rebase

pull 命令的背地是主动帮咱们做 merge 的，然而这里以 rebase 的模式，再来看一下 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

咱们的 feature1 性能 on top of main 的提交节点，还是放弃线性，接下来就能够 push 代码，而后提 PR，将你的 feature merge 到 main 分支了

简略形容 merge 和 rebase 的区别就是这样的：

我这里应用 git pull origin main --rebase 省略了切换 main 并拉取最新内容再切回来的过程，一步到位，背地的原理都是上图展现的这样

应用 rebase 是要恪守一个黄金法令的，这个之前有说过，就不再是赘述了

总结

有了这三个锦囊，置信大家的 git log 都无比的清晰，如果你还不晓得，齐全能够用起来，如果你的组内成员不晓得，你齐全能够推广起来，这样的 repo 看起来才更衰弱

接下来会介绍一个多分支切换互不影响的锦囊

日拱一兵 | 原创