使用version 以外的命令。例如,尝试将 l 别名为 log。 (或者,正如 VonC 所说,升级——它实际上确实在现代 Git 中工作。别名处理似乎已在 2.17.3 和 2.18.0 之间重写。)
为什么l = log 有效,而v = version 无效?
这有点棘手!
大多数 Git 命令是——并且在某一时刻,所有Git 命令曾经——独立的程序被单独安装到一个目录(或文件夹,如果你更喜欢这个词的话) 充满了“你可以运行的 Git 命令”。比如git log实际上是由一个拼写为git-log的命令实现的,它安装在一个特殊的目录/文件夹中。
这个目录/文件夹不是你通常运行的命令从,虽然。
在遥远的过去,这些 Git 命令——git-log、git-commit、git-add、git-diff 等等——都是直接安装的,你直接运行它们,输入 git-<em>something</em> .这适用于 bash 的自动完成功能,因为您可以输入 git-com<kbd>TAB</kbd> 来获取提交命令,或者输入 git-ch<kbd>TAB</kbd> 来获取签出命令。但随着时间的推移,Git 命令的数量越来越多(git-cherry 和 git-cherry-pick),越来越多;越来越多;最终甚至输入完整的命令git-add 也不够 因为还有git-add--interactive 例如,所以 TAB 完成基本上完全停止工作。
做出了一个决定:Git 不会停止提供 57 个不同的命令(实际上,现在已经超过 150 个),而是将所有这些不同的实现命令塞进一个地方他们不会一直都在你面前。 单个前端命令,拼写为git,可以让您将命令作为参数输入到前端git命令:git com,然后TAB:bash 现在有一个 list allowed 补全,并且只会选择commit,因为这是唯一的com 您将使用,而不是只有脚本经常使用的git-commit-tree 或git-commit-graph 后端程序。
所以:前端 git 命令知道如何查找和运行所有各种后端 实现。按照惯例,大部分都在git-core目录下:运行
git --exec-path
前端打印出所有后端程序实际所在位置的名称。 (你可以在那里查看,如果你愿意,甚至可以直接从那里运行它们,尽管现在前端 git 命令现在设置了后端命令可能需要的信息。)
但是git version 呢?好吧,既然您知道 Git 命令实际上存在于 git-core 文件夹中,无论它在您的系统上的什么地方,我建议您查看那里。 git-version 程序在哪里?您会在其中找到git-checkout、git-log、git-commit、git-diff 和许多其他人,但您不会找到git-version。没有。
version 命令直接内置于前端。 aliases 仅在调用 back end 命令时起作用。因此,无论如何,没有办法给version 起别名。 (在某些时候,显然是 2.9 和 2.24 之前的版本,别名处理代码也被智能地检查了前端内置。)
还有一件更重要的事情需要了解
前端git 命令确实知道一些常见的后端命令,但它不有一个完整列表后端命令。相反,当您输入 git asdf 或 git rumplestiltskin 或 git helloworld(这些都不是实际的 Git 命令)时,它只是照常设置,然后 尝试 运行 git-asdf 或 @ 987654366@ 或git-helloworld,同时告诉系统查看git-core 目录。它不会告诉系统不去查看其他目录。
这意味着你可以编写你自己的 Git 命令。如果你想要一个git asdf,你可以编写你自己的git-asdf 程序,把它放在任何地方,这样git-asdf 就可以成功运行。您现在可以使用git asdf 运行它。
为什么,您可能想知道,您想要这样做吗?如果您在自己的个人 bin 或脚本文件夹中安装 git-asdf,则只需运行 git-asdf。事实上,你可以做到这一点。但是,当您让 前端 运行它时,您会在运行时提供特殊的 Git 设置信息。这使您能够将程序编写为 sh(或 bash)脚本并直接访问各种 Git 助手。主要助手称为git-sh-setup,您可以通过“采购”它来调用它,使用.(POSIX)或source(bash):
#! /bin/sh
. git-sh-setup
这增加了 shell 函数 die 和 say 和 git_pager 和 require_clean_work_tree 等等。如果您在获取git-sh-setup 之前设置了shell 变量OPTIONS_SPEC,它将为您解析参数。查看脚本——它就在git-core 目录中——了解如何使用它。
(请注意,就像所有 Git 一样,它随着时间的推移而发展。例如,它现在的功能比 Git 1.7 时代的更多。如果您想要向后移植到旧版本的 Git,请克隆Git 的 Git 存储库,选择一个兼容级别,然后 git checkout 旧的,看看你可以依赖什么。)