猿猿有责,维持整洁的 Git 提交记录,三个锦囊送给你

简介: 猿猿有责,维持整洁的 Git 提交记录,三个锦囊送给你

背景


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


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


微信图片_20220512120457.png

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


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


善用 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


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


微信图片_20220512120805.png


有了 --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 最常用的是 squashfixup, 前者包含 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


微信图片_20220512121009.png


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 的区别就是这样的:


微信图片_20220512121043.gif


image.gif



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


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


总结


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


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

相关文章
|
持续交付 开发工具 git
如何保留原提交记录迁移Git项目,你还不知道吗?
如何保留原提交记录迁移Git项目,你还不知道吗?
如何保留原提交记录迁移Git项目,你还不知道吗?
|
Shell 开发工具 git
Git基础使用-如何用Git把代码提交至仓库/新建仓库/同步代码/推送代码
Git基础使用-如何用Git把代码提交至仓库/新建仓库/同步代码/推送代码
448 0
|
开发工具 git
git操作日常记录学习
git操作日常记录学习
|
Shell 开发工具 数据安全/隐私保护
Git提交之后自动打版本并钉钉通知
Git提交之后自动打版本并钉钉通知
417 0
Git提交之后自动打版本并钉钉通知
|
开发工具 git
phpstrom git 修改文件就提交方法
phpstrom git 修改文件就提交方法
73 0
phpstrom git 修改文件就提交方法
|
数据可视化 Java 数据库连接
忽略不想提交的文件- 每天三分钟玩转Git(10)大结局
忽略不想提交的文件- 每天三分钟玩转Git(10)大结局
忽略不想提交的文件- 每天三分钟玩转Git(10)大结局
|
数据可视化 开发工具 git
漏提交与打tag- 每天三分钟玩转Git(9)
漏提交与打tag- 每天三分钟玩转Git(9)
漏提交与打tag- 每天三分钟玩转Git(9)
|
开发工具 git
撤销远程提交-每天三分钟玩转Git (6)
撤销远程提交-每天三分钟玩转Git (6)
撤销远程提交-每天三分钟玩转Git (6)
|
安全 开发工具 git
撤销本地提交-每天三分钟玩转Git (5)
撤销本地提交-每天三分钟玩转Git (5)
撤销本地提交-每天三分钟玩转Git (5)
|
缓存 前端开发 JavaScript
git 提交之规范校验 (eslint+husky+prettier)
git 提交之规范校验 (eslint+husky+prettier)
git 提交之规范校验 (eslint+husky+prettier)