维持整洁的Git提交记录

背景

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

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

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

代码都提交了，那还有什么办法拯救吗？三个锦囊，就可以完美解决了

善用 git commit --amend

这个命令的帮助文档是这样描述的：

--amendamendpreviouscommit

也就是说，它可以帮助我们修改最后一次提交

既可以修改我们提交的 message，又可以修改我们提交的文件，最后还会替换最后一个 commit-id

我们可能会在某次提交的时候遗漏了某个文件，当我们再次提交就可能会多处一个无用的 commit-id，大家都这样做，git log 慢慢就会乱的无法追踪完整功能了

假设我们有这样一段 log 信息

*98a75af(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1.2
*119f86efeat:[JIRA123]addfeature1.1
*5dd0ad3feat:[JIRA123]addfeature1
*c69f53d(origin/main,origin/feature/JIRA123-amend-test,origin/HEAD,main)Initialcommit

假设我们要修改最后一个 log message，就可以使用下面命令：

gitcommit--amend-m"feat:[JIRA123]addfeature1.2and1.3"

我们再来看一下 log 信息, 可以发现，我们用新的 commit-id5e354d1替换了旧的 commit-id98a75af, 修改了 message，并没有增加节点

*5e354d1(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1.2and1.3
*119f86efeat:[JIRA123]addfeature1.1
*5dd0ad3feat:[JIRA123]addfeature1
*c69f53d(origin/main,origin/feature/JIRA123-amend-test,origin/HEAD,main)Initialcommit

现在我们的 repo 中文件是这样的：

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

0directories,2files

假设我们提交feature 1.3的时候，忘记了一个配置文件config.yaml, 不想修改 log，不想添加新的 commit-id，那下面的这个命令就非常好用了

echo"feature1.3configinfo">config.yaml
gitadd.
gitcommit--amend--no-edit

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

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

0directories,3files

再来看一下 git log

*247572e(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1.2and1.3
*119f86efeat:[JIRA123]addfeature1.1
*5dd0ad3feat:[JIRA123]addfeature1
*c69f53d(origin/main,origin/feature/JIRA123-amend-test,origin/HEAD,main)Initialcommit

知道这个技巧，就可以确保我们的每次提交都包含有效的信息了。一张图描述这个过程就是这个样子了：

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

善用 git rebase -i

可以看着，上面的 log 都是在开发 feature1，我们在把 feature 分支 merge 到 main 分支之前，还是应该继续合并 log commit 节点的，这就用到了

gitrebase-iHEAD~n

其中 n 代表最后几个提交，上面我们针对 feature 1 有三个提交，所以就可以使用：

gitrebase-iHEAD~3

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

1pick5dd0ad3feat:[JIRA123]addfeature1
2pick119f86efeat:[JIRA123]addfeature1.1
3pick247572efeat:[JIRA123]addfeature1.2and1.3
4
5#Rebasec69f53d..247572eontoc69f53d(3commands)
6#
7#Commands:
8#p,pick=usecommit
9#r,reword=usecommit,buteditthecommitmessage
10#e,edit=usecommit,butstopforamending
11#s,squash=usecommit,butmeldintopreviouscommit
12#f,fixup=like"squash",butdiscardthiscommit'slogmessage
13#x,exec=runcommand(therestoftheline)usingshell
14#d,drop=removecommit
15#l,label=labelcurrentHEADwithaname
16#t,reset=resetHEADtoalabel
17#m,merge[-C|-c][#]
18#.createamergecommitusingtheoriginalmergecommit's
19#.message(ortheoneline,ifnooriginalmergecommitwas
20#.specified).Use-ctorewordthecommitmessage.
21#
22#Theselinescanbere-ordered;theyareexecutedfromtoptobottom.
23#
24#IfyouremovealinehereTHATCOMMITWILLBELOST.
25#
26#However,ifyouremoveeverything,therebasewillbeaborted.
27#
28#
29#Notethatemptycommitsarecommentedout

合并 commit-id 最常用的是squash和fixup, 前者包含 commit message，后者不包含，这里使用 fixup, 然后:wq退出

1pick5dd0ad3feat:[JIRA123]addfeature1
2fixup119f86efeat:[JIRA123]addfeature1.1
3fixup247572efeat:[JIRA123]addfeature1.2and1.3

我们再来看一下 log, 这就非常清晰了

*41cd711(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1
*c69f53d(origin/main,origin/feature/JIRA123-amend-test,origin/HEAD,main)Initialcommit

善用 rebase

上面的 feature1 已经完整的开发完了，main 分支也有了其他人的更新，在将 feature merge 回 main 分支之前，以防代码有冲突，需要先将 main 分支的内容合并到 feature 中，如果用 merge 命令，就会多处一个 merge 节点，log history 中也会出现拐点，并不是线性的，所以这里我们可以在 feature 分支上使用 rebase 命令

gitpulloriginmain--rebase

pull 命令的背后是自动帮我们做 merge 的，但是这里以 rebase 的形式，再来看一下 log

*d40daa6(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1
*446f463(origin/main,origin/HEAD)Createmain.properties
*c69f53d(origin/feature/JIRA123-amend-test,main)Initialcommit

我们的 feature1 功能on top ofmain 的提交节点，还是保持线性，接下来就可以 push 代码，然后提 PR，将你的 feature merge 到 main 分支了

简单描述 merge 和 rebase 的区别就是这样的：

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

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

总结

有了这三个锦囊，相信大家的 git log 都无比的清晰，如果你还不知道，完全可以用起来，如果你的组内成员不知道，你完全可以推广起来，这样的 repo 看起来才更健康。