维持整洁的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.txt0 directories, 2 files 假设我们提交 feature 1.3 的时候，忘记了一个配置文件 config.yaml, 不想修改 log，不想添加新的 commit-id，那下面的这个命令就非常好用了
echo feature 1.3 config info > config.yamlgit add .git commit --amend --no-edit git commit --amend --no-edit 就是灵魂所在了，来看一下当前的 repo 文件：
.├── readme.md├── config.yaml└── feat1.txt0 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 = use commit 9 # r, reword = use commit, but edit the commit message 10 # e, edit = use commit, but stop for amending 11 # s, squash = use commit, but meld into previous commit 12 # f, fixup = like squash, but discard this commit's log message 13 # x, exec = run command (the rest of the line) using shell 14 # d, drop = remove commit 15 # l, label = label current head with a name 16 # t, reset = reset head to a label 17 # m, merge [-c | -c ] [# ] 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 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 看起来才更健康。
再见了，25岁的Flash Player
XD3E系列入门级以太网型PLC简介
芯片，是如何加速5G手机的普及？
规模商用加速5G技术成熟进程
5G有可能成为一个失败通信技术
维持整洁的Git提交记录
台积电3nm工艺晶圆价格飙升，收入激增
红外LED反向雪崩击穿测试
教你当你手机通话记录丢失后如何快速找回
单晶金刚石中的低损耗毫米波导和光栅耦合器
LCD使用时需要注意的几个小问题，AT89C51写入字符LCD点阵源代码分享
Android遇麻烦，或将被谷歌新系统Fuchsia替代
凯文·艾希顿演讲：物联网十大趋势
如何来设计针对FPGA系统电源
大联大集团推出TOSHIBA和AMS的适用于VR的多种解决方案
VM700T VM700T VM700A VM700 视音频
大米重金属快检仪产品的功能特点是怎样的
华为或将在9月推出高端电视产品 却并不只局限在高端领域
国创中心与博泰车联网正式成立“车规集成电路联合实验室”
Intel 11酷睿无核显F系列曝光 不见最顶级的“i9-11900KF”
最常见的问题就是乱成一团的 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.txt0 directories, 2 files 假设我们提交 feature 1.3 的时候，忘记了一个配置文件 config.yaml, 不想修改 log，不想添加新的 commit-id，那下面的这个命令就非常好用了
echo feature 1.3 config info > config.yamlgit add .git commit --amend --no-edit git commit --amend --no-edit 就是灵魂所在了，来看一下当前的 repo 文件：
.├── readme.md├── config.yaml└── feat1.txt0 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 = use commit 9 # r, reword = use commit, but edit the commit message 10 # e, edit = use commit, but stop for amending 11 # s, squash = use commit, but meld into previous commit 12 # f, fixup = like squash, but discard this commit's log message 13 # x, exec = run command (the rest of the line) using shell 14 # d, drop = remove commit 15 # l, label = label current head with a name 16 # t, reset = reset head to a label 17 # m, merge [-c | -c ] [# ] 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 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 看起来才更健康。
再见了，25岁的Flash Player
XD3E系列入门级以太网型PLC简介
芯片，是如何加速5G手机的普及？
规模商用加速5G技术成熟进程
5G有可能成为一个失败通信技术
维持整洁的Git提交记录
台积电3nm工艺晶圆价格飙升，收入激增
红外LED反向雪崩击穿测试
教你当你手机通话记录丢失后如何快速找回
单晶金刚石中的低损耗毫米波导和光栅耦合器
LCD使用时需要注意的几个小问题，AT89C51写入字符LCD点阵源代码分享
Android遇麻烦，或将被谷歌新系统Fuchsia替代
凯文·艾希顿演讲：物联网十大趋势
如何来设计针对FPGA系统电源
大联大集团推出TOSHIBA和AMS的适用于VR的多种解决方案
VM700T VM700T VM700A VM700 视音频
大米重金属快检仪产品的功能特点是怎样的
华为或将在9月推出高端电视产品 却并不只局限在高端领域
国创中心与博泰车联网正式成立“车规集成电路联合实验室”
Intel 11酷睿无核显F系列曝光 不见最顶级的“i9-11900KF”