24

Gitコマンドを拡張する簡単な方法があるかどうか疑問に思いました。

したがって、次のようなコマンドを作成できます。

git my-custom-made-extension --my-options <my-other-arguments>

完璧な世界では、私はそれを好きな言語で行うことができ、カスタムメイドの拡張機能を任意の開発環境にかなり簡単に追加することができます。

たとえば、 Vimでのプラグインのサポートのようなものですか?

4

3 に答える 3

33

のソースコードでわかるexecv_dashed_externalように、コマンドを実行するとgit-my-custom-made-extension、gitは次のようにエイリアスします。

  • git my-custom-made-extension ...git-my-custom-made-extension ...
  • git help my-custom-made-extensionman git-my-custom-made-extension

「gitの拡張」について特別なことは何もありません。通常どおりにプログラムを作成し、名前が。で始まることを確認しgit-ます。

于 2012-06-11T10:21:39.260 に答える
13

実際の例

周りを見回すと、Gitコマンドラインを拡張するプロジェクトがたくさんあります。

  • git-wtf(Rubyで書かれています)実行可能ファイルを入れるためにbrewまたは手動インストールを使用します/usr/bin(またはそれでした/usr/localか?)。そして、Gitには、あなたが書くときgit wtfに実際にPATHという名前のスクリプトを探していることを知っているメカニズムがあるようですgit-wtf
  • git-annex(haskellで書かれている)より複雑なフレーバーがあります。ただし、インストールにCabalを使用している場合でも(インストールに依存関係がない場合は依存関係のリストが長い)、git-wtfと同じ基本原則を使用しているようです。(Gitは、書き込み時に実行可能パスでそれを見つけますgit annex
  • git-flow(シェルで記述)brew / macport / apt-get / wget+bashを使用して自身をインストールします。そして、もう一度、それは同じメカニズムを使用しているようです。

解決 (?)

したがって、独自のカスタムスクリプトを作成し、PATH変数にリストされている任意のパスに配置することで利用できるようにすることは確かに可能です。

しかし、私が知る限り、いくつかの欠点があります...

既知の問題点

ドキュメント

Gitを実際に拡張していないため、一部のコマンドが機能していません。

$ git help wtf
No manual entry for git-wtf
$ git wtf --help
No manual entry for git-wtf
$ git wtf -h # the only command which works...
Usage: git wtf [branch+] [options]
...

私はgit-annexで試していないので、この問題を回避できた可能性がありますが、git-flowとgit-wtfはこの動作に従います。

編集git helpマニュアルページへのフォールバックなので、この点は一種の無関係です(ThxEric)。

インストールプロセス

Brew、macports、apt-getによるインストールは素晴らしいです。しかし、Gitに機能を追加するための世界的に受け入れられている方法はありません。具体的には、「プラグイン」をインストールするプラットフォームに依存しない方法はありません。たぶんmakeそのトリックを行うでしょうが、それでもあなたは自分でインストールスクリプトを書かなければならないでしょう。

于 2012-06-11T10:19:50.647 に答える
1

手動またはでエイリアスを作成することをお勧めしますgit configマニュアルページでこれについて詳しく説明しています。本当に基本的な例は次のようになります。

git config --global alias.log1 "log --oneline"
于 2012-06-11T15:21:46.400 に答える