如果你是一个开发者,你大概率每天都在用 git log。
但你可能不知道——或者没在意——Git 还有一个被严重低估的命令:git log 的 –graph 和各种历史重构工具,以及一个叫 git rebase -i 的交互式神器。
等等,不是说 git history 吗?
其实 Git 本身没有一个叫 history 的命令,但有一整套操作历史的工具和参数选择,用好它们,你的开发效率和代码管理能力能提升一个量级。
你以为的 git log 只是冰山一角
大多数人用 git log 只是:
1 | git log |
但你看看这个:
1 | # 带分支拓扑图的日志,一眼看清合并关系 |
是不是感觉打开了新世界的大门?这些组合能让你在几百条提交中秒速定位任何改动。
真正的神器:交互式变基
如果说 git log 只是「看」历史,那 git rebase -i 就是 「改写」历史的神器。
1 | git rebase -i HEAD~5 |
执行后会打开一个编辑器,展示最近 5 个提交,每个前面都可以加一个命令:
pick — 保留(默认)
reword — 保留提交,但修改提交信息
edit — 停下来修改提交内容
squash — 合并到上一个提交(合并后保留提交信息)
fixup — 合并到上一个提交(丢弃提交信息)
drop — 删除这个提交
实战场景一:把杂乱的提交整理成干净的 PR
你折腾了一天,提交了 12 次,信息分别是:
1 | 1. 改了一点 |
这样的提交记录发 PR,reviewer 会疯掉。用 git rebase -i HEAD~12,把大部分改成 fixup 合并到第一个提交,最后变成一条干净整洁的提交。
实战场景二:把一个提交拆成多个
用 edit 标记一个提交,Git 会停下来让你用 git reset HEAD^ 把它的改动拆开,然后分多次提交。
git bisect:二分查找「谁搞崩了代码」
这是 Git 最被低估的功能之一,没有之一。
1 | git bisect start |
在大型项目中,二分查找可以在几十次提交中 O(log n) 定位问题——比人工查找快 100 倍。
git blame:逐行追责(不是追责)
1 | git blame file.txt |
告诉你每一行是谁在什么时候写的。不是为了甩锅,而是:
- 改代码前知道原作者是谁,可以拉来问「当年这么写是为什么」
- 发现一行诡异的代码,查提交记录看当时的上下文
- 重构前快速评估代码的「年龄」——#老代码要小心
git reflog:你的后悔药
这是 Git 最温暖的命令。
1 | git reflog |
你以为你搞丢了代码?你以为 git reset --hard 把改了一天的代码都丢了?去跑一下 git reflog,Git 会在本地记录你所有的 HEAD 变更历史——包括那些「被删除」的提交。只要 repo 还在,90% 的误操作都有救。
从今天开始,做个 Git 高手
很多人觉得 Git 就是 add、commit、push、pull 这四个命令。但真正用好 Git 的人,能把它变成一个强大的「代码时间旅行器」。
你不需要记住所有命令——记住这些就够了:
| 场景 | 命令 |
|---|---|
| 可视化历史 | git log --graph --oneline --all |
| 搜索历史 | git log --grep / -S |
| 整理提交 | git rebase -i |
| 找 bug 来源 | git bisect |
| 查行归属 | git blame |
| 后悔药 | git reflog |
| 撤销最近提交 | git revert HEAD |
把这几个用熟了,你的 Git 水平已经超过了 90% 的开发者。
参考:The Git history command deserves more attention — Lalit Maganti
本文作者:Samjoe Yang
本文链接: https://need.uno/git-gao-ji-wan-fa-log-zhi-wai-de-bao-cang-ming-ling/
版权声明:本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。
评论