你知道git有多少命令吗?盘点那些你可能没见过但很有用的git命令

Scott Chacon 在今年有一个演讲题目名为：# So You Think You Know Git。

这个一个非常棒的演讲，非常建议你去看一看原视频。本文基本上是对演讲中提到的部分内容的重新阐述。不要被这个标题吓到，这不是什么晦涩的 git 原理讲解文章。放松心情，Let's go！

演讲者是 Scott Chacon。github 联合创始人，《Pro Git》的作者。

git 有多少命令？

145 个！

包括我们常用的 push / pull / merge /rebase，也有很多你可能根本没听说过的 apply / blame / fetch-back 等...

git 诞生于 2005 年，到今天它依然非常活跃。git 的代码仓库平均每天会有 9 次代码提交。让我们看看这个星球上最成功的版本管理工具有什么有用或者有趣的命令吧。

git config

git 别名

我们先从 git config 讲起, 使用 alias 可以为我们经常使用的 git 命令配置别名，比如：git config --global alias.staash 'stash --all'。 先回顾一下 git stash 和 git stash --all 的区别：

• git stash：这个命令会储藏工作区和暂存区的修改。也就是说，它会储藏你已经修改但还没有提交的文件。但是，它不会储藏未跟踪的文件（你新创建的但还没有添加到 Git 的文件）。
• git stash --all：这个命令会储藏所有的修改，包括工作区和暂存区的修改，以及未跟踪的文件。 就我的日常工作而言，git stash --all 是更为常用的命令，使用 alias 可以更方便的使用命令。

执行自定义脚本

git config --global alias.bb !better-branch.sh。通过别名，我们也可以将我们自定义的 shell 脚本包装为 git 命令。在这个例子中，使用 git bb 即可执行 better-branch.sh。

includeIf

includeIf 是 Git 配置中的一个指令，它允许你根据特定的条件来包含 git 配置文件。

这个功能在很多情况下都很有用。例如，你可能在不同的项目中使用不同的 git 配置。你可以为每个项目创建一个单独的配置文件，然后使用 includeIf 指令来根据项目的路径来选择性地包含这些配置文件。

下面是一个例子：

[includeIf "gitdir:~/work/"]
    path = ~/work/.gitconfig // user.email = 'xxx@company.com'
    
[includeIf "gitdir:~/oss/"]
    path = ~/oss/.gitconfig // user.email = 'xxx@github.com'

我在 work 路径下放置的是公司工作的代码，配置的邮箱是公司的邮箱。而在 oss 路径下是参与开源项目的代码，配置的邮箱是 github 的邮箱。

一些旧功能

git 一直存在的功能！看看有哪些你是不知道的！

git blame -L

git blame 的主要作用是显示指定文件是由哪些开发者在何时进行的修改。对于文件中的每一行，git blame 命令都会显示最后修改这一行的 commit，作者和时间。

正如它的名字：blame，一般出现问题需要找人背锅时，可以使用 blame 来看看这行代码最后是谁提交的（笑）。

那 git blame -L 呢？可以指定行数，缩小 git blame 的范围，例如 git blame -L 28,43 path/to/file：

git blame -w

git blame 很好用。但在有一种场景下，比如你用了 lint 工具格式化了一个文件，将代码缩进从两格变成了四格。这个时候使用 git blame 就全是你的提交记录！

使用 该 git blame -w 选项将忽略这些类型的空格更改。

还有更智能的变体：git blame -w -C，除了查看文件的修改历史，还查看文件的复制历史。也就是说，如果一部分代码是从文件的其他部分复制过来的，git blame 将会把这部分代码的修改归因于原来的代码。

在这个基础上，你甚至可以进一步套娃🤯：

• git blame -w -C：查找文件内部的复制代码；
• git blame -w -C -C：除了查找文件内部的复制代码，还查找其他文件的复制代码；
• git blame -w -C -C -C：除了查找文件内部和其他文件的复制代码，还查找跨越多个文件的复制代码。

妈妈再也不用担心我背锅啦！

diff 每一个单词

默认情况下，git diff 会对比行的差异。其实 git diff 也可以对比细粒度到单词，这在某些需要查看文档改动时比较有用，比如下面的例子：

git diff

git diff --word-diff

git rerere

"Reuse Recorded Resolution"（复用已记录的解决方案）的主要作用是在解决合并冲突时复用之前的解决方案。

当你在 Git 中进行合并（merge）或者拉取（pull）操作时，有可能会遇到冲突。这时，你需要手动解决这些冲突，然后将解决方案记录到 Git 中。

如果你在后续的操作中遇到了相同的冲突，你可以使用 git rerere 功能来自动应用之前的解决方案！

使用 git config 可以自动开启它：

$ git config --global rerere.enabled true
$ git config --global rerere.autoUpdate true

笔者注：这看起来像是个魔法🪄 需要注意 Reuse Recorded Resolution 只能在冲突的上下文没有改变的情况下正常工作。我在实际工作中并没有遇到过需要广泛使用它的场景。暂不做深入介绍。

一些新玩意

分支排序

Git Branch 不是什么新东西，它默认是以最愚蠢的字母顺序排列的。现在你可以选择设置它的排序规则：

# 使用提交日期降序排序
$ git config --global branch.sort -committerdate

如果 git branch 太多！你可以让他更为紧凑的显示在屏幕上：

git config --global column.ui auto

效果如下： cool！

git push --force-with-lease

考虑这种场景，小明在分支 feat 上提交了 commit：

add some magic🪄

push 到远端后，小明想改点东西，于是用 git commit --amend 修改了这个 commit。这个时候本地的 commit 和远端的不一致了，小明掏出了 git push --force 强制覆盖了远端代码，满意的下班了。

一般来说，这样没什么问题！

但是如果小明和同事小强在同一个分支工作，问题就来了，小明在分支 feat 上提交了 commit，小强也提交了自己的 commit。小强提交完满意地下班了。这个时候小明修改了自己的代码，掏出了 git push --force 强制覆盖了远端代码。

第二天小强一来上班发现自己的代码被覆盖了！提着刀就去了小明的工位。

git push --force-with-lease 就是用来应对这种场景。他可以看作是一个更安全的 git push --force。--force-with-lease 选项在强制更新新分支之前，会检查您上次推送的内容是否仍然是服务器上的内容。

如果有人更新了远程引用（同时推送），则会推送失败。

如果你经常用 git push --force，可以添加一个别名，比如：

git config --global alias.fpush push --force-with-lease

May the force be with you.

SSH 提交验证

你逛 github 的时候肯定看到过有的 commit 上会打上一个 verified 的标记。 Verified 标签的主要意义在于提供了一种验证机制，确保提交的真实性和完整性。这对于开源项目尤其重要，它可以帮助维护者确认提交是由特定的贡献者完成的，并且在提交过程中没有被修改。

Git 支持使用 GPG 签署提交已经有一段时间了，但如果你以前从未使用过 GPG，别担心，现在 github 可以使用 SSH 验证。具体内容可以看看这篇文章。

Git Maintenance

git maintenance start，用于自动启动 Git 仓库的后台维护任务。这个命令会在你的系统上安排定期的 Git 维护任务，这些任务包括：

• 清理：Git的垃圾收集器会清理那些不再需要的文件和对象，以减少仓库的大小；
• 压缩：Git会重新打包你的对象。这个过程会将多个小文件合并成一个大文件，从而提高Git的性能；
• 修复：如果Git仓库出现了问题，Git会检查和修复它。

如果你想要停止后台的维护任务，你可以运行 git maintenance stop 命令。这对于代码仓库很大的场景非常有用！试一试吧。

wrap up

以上是对演讲中提到的有意思的 git 相关的内容的一个总结。演讲中还有针对大型仓库的相关内容。感兴趣的话可以看一看原视频。

感谢阅读～