Summary：製品にバージョン情報を埋め込むには、ビルドシステムを使用することをお勧めします。詳細と代替アプローチについては、以下を参照してください。
Gitでは（通常、アトミックコミットを使用する他のVCSシステムでもそうだと思います）、version of a single fileのようなものはありません。
Gitは$Id:$キーワードのオンデマンド拡張をサポートしていますが、
- リクエストに応じてのみ行われます。ファイル（またはファイルのセット）が
identattribute set（in '.gitattributes' file in tree、or '.git/info /）を持っていることを（おそらくグロビングパターンを使用して）指定する必要がありますローカルリポジトリ設定の属性）。 - これはファイル内容のSHA-1（またはより正確には
$Id:<sha-1 of blob>$）に展開されます。この選択の理由は、ブランチの切り替えまたは巻き戻し中に変更されていないファイルにはGitが触れないためです。 「$ Id：$」がリビジョン情報に展開された場合、everyバージョン管理されたファイルを更新する必要があります。ブランチを切り替えるとき。
Gitは、情報をコミットするように拡張された非常に幅広い$Format:...$プレースホルダーセットをサポートしています（たとえば、$Format:%H$はコミットハッシュに置き換えられます）。
- 展開は、出力ファイルでgit archiveを実行している場合にのみ行われます。
- リクエストに応じてが行われ、
export-subst属性によって制御されます。
バージョン情報を埋め込むには、ビルドシステムを介して（ビルドステージで）行うことをお勧めします。たとえば、Git Makefile および GIT-VERSION-GEN git.gitリポジトリのGit WebインターフェイスでMakefileによって使用されるスクリプトを参照してください。
ただし、（filter属性を介して）クリーン/スマッジフィルタードライバーを（ab）使用して、CVSに似たキーワード展開、チェックアウト時にキーワードを展開し、コンテンツをリポジトリに入力するときにそれらをクリーンアップできます。
これを行うには、この機能を必要とするファイルのパターンを追加し、その後に.gitattributesファイルにidentを追加します。これにより、ファイルのチェックアウト時に$ Id $が$ Id：<40桁のSHA> $に置き換えられます。ただし、CVS/SVNの場合のように、ファイルのリビジョン番号が表示されないことに注意してください。
例：
$ echo '*.txt ident' >> .gitattributes
$ echo '$Id$' > test.txt
$ git commit -a -m "test"
$ rm test.txt
$ git checkout -- test.txt
$ cat test.txt
Gitのidentは、他のバージョン管理システムで$ Id $が行うことを行いません。慣習として、個別のファイルリビジョンにはRCSとgit：RCSを併用し、プロジェクト全体にチェックポイントを設定するにはgitを使用します。私が言ったように、これはkludgeですが、それは（時にはいくつかの事柄に対して）ある程度意味があります。
JakubNarębski 提案 彼の答え （10年以上前）：
ただし、（abs）clean/smudgeフィルタードライバーを（filter属性を介して）使用して、CVSのようなキーワード展開、チェックアウト時のキーワードの展開、およびリポジトリへのコンテンツの入力時のクリーンアップを行うことができます。
批判は（ Arioch 'Theコメント による）
フィルタードライバーは、実際にパワーがあれば、本当にすばらしいでしょう。
現在のところ、onlyファイル名をパラメータとして取得しているようです：identフィルター。BLOBSHA1をパラメーターとして取得します。
Git 2.27（2020年第2四半期）では、gitコンテンツフィルターはもはや無力です！
Git 2.27は詳細情報を提供します（たとえば、すでにパスされているパスに加えて、変換されているブロブが表示されるツリーっぽいオブジェクトスマッジ/クリーン変換フィルターに与えられます。
commit 0c0f8a7 、 commit 4cf76f6 、 commit 3f26785 、 commit dfc8cdc 、 commit 13e7ed6 を参照してください、 commit c397aac 、 commit ab90eca （2020年3月16日）、および commit a860476 （2020年3月10日）by brian m.carlson （ ``） 。
（ Junio C Hamano-gitster- によってマージ commit 4e4baee 、2020年3月27日）
convert：プロセスをフィルタリングするために追加のメタデータを渡すことを許可しますサインオフ：brian m。カールソン
フィルタープロセスで追加のメタデータを利用できる状況はさまざまです。
たとえば、一部のユーザーは、identフィルターの制限が高すぎると感じ、汚されたファイルにコミットまたはブランチを含めたいと考えています。
HEADはその時点で更新されておらず、アーカイブでも利用できないため、チェックアウト中はこの情報は利用できません。
このメタデータをフィルターに渡す方法を追加しましょう。
操作しているblob、treeish（存在する場合はツリーよりもcommitを優先）、操作しているrefを渡します。
再正規化時やdiffの実行時など、すべてのケースでこの情報を渡すわけではないことに注意してください。これらのケースでは意味がありません。
現在フィルタープロセスから取得するデータは次のようになります。
command=smudge pathname=git.c 0000この変更により、次のようなデータが取得されます。
command=smudge pathname=git.c refname=refs/tags/v2.25.1 treeish=c522f061d551c9bb8684a7c3859b2ece4499b56b blob=7be7ad34bd053884ec48923706e70c81719a8660 0000このアプローチについて注意すべき点がいくつかあります。
チェックアウトなどの操作の場合、個々のツリーをチェックアウトできないため、treeishは常にコミットになりますが、アーカイブなどの他の操作の場合、特定のツリーのみを操作することになるため、ツリーのみとしてツリーのみを提供します。
Refを持たないさまざまなケースがあるため、同様のコメントがrefnameに適用されます。
そして：
convert：フィルターに追加のメタデータを提供しますサインオフ：brian m。カールソン
追加のメタデータをフィルターに渡すためにコードベースが接続されたので、渡したい追加のメタデータを収集しましょう。
このメタデータを渡す2つの主な場所は、チェックアウトとアーカイブです。
これらの2つの状況では、HEADは、HEADが作業ツリーの後までチェックアウト用に更新されないため、有効なオプションではありません。が書き込まれ、アーカイブは任意のツリーを受け入れることができます。他の状況では、HEADは通常、現在使用中のブランチの参照名を反映します。
git cat-fileのような他のケースでは、より少量のデータを渡します。この場合、ブロブについて論理的にしか知ることができません。