1. ホーム
  2. git

[解決済み] git ignore と exclude と assume-unchanged の比較

2023-04-27 05:03:11

質問

これに関するドキュメントを何度も読み返しましたが、これらの異なるコマンドの違いを完全に理解することはできません。私だけかもしれませんが、ドキュメントはもっと明瞭であるべきです。

http://git-scm.com/docs/gitignore

https://help.github.com/articles/ignoring-files

さらに、この件に関する多くの解説では、quot;indexed", "committed", "tracked" という言葉がやや緩やかに使われているようで、これらの違いがあまり明確ではなくなってきています。

私の現在の (確かに限られた) 理解です。

  • でマッチしたファイル .gitignore にマッチしたファイルは今後追跡されません。 (以前は追跡されていたかもしれませんが)。 に表示されないということです。 git status のリストには表示されないということです。 しかし、将来の変更はリモート リポジトリの . 言い換えれば、ファイルはまだ"indexed"ですが、それらは"tracked"ではありません。 なぜなら .gitignore ファイルがプロジェクトディレクトリにあるため、そのファイル自体もバージョン管理できます。 はプロジェクト ディレクトリにあるため、ファイル自体をバージョン管理することができます。

  • でマッチしたファイルは .git/info/exclude でマッチしたファイルもまた、"tracked" されません。さらに さらに、これらのファイルはリモートで同期されることがないため、他のユーザーからどのような形でも見られることはありません。 他のユーザーからどのような形であれ見られることはありません。これらのファイルは、次のようなファイルである必要があります。 は、1人のユーザーのエディターまたはワークフローに固有のファイルである必要があります。なぜなら、このファイルは .git ディレクトリにあるため exclude ファイル自体をバージョン管理することはできません。

  • を持っているファイルは assume-unchanged が実行されたファイルは git status または git diff . これは exclude これらのファイルは "indexed" も "tracked" もないという点で、quot;indexed" と同じです。しかし、その前にコミットされるファイルの最後のバージョンは assume-unchanged の前にコミットされたファイルの最終バージョンは、レポ内のすべてのユーザーから見える状態で残ります。

私の質問

  1. 上記の解釈は正しいのでしょうか?訂正をお願いします。

  2. あるファイルがすでにコミットされていた場合、そのファイルをコミットするのと でのマッチングとの機能的な違いは何でしょうか? .exclude でマッチさせるのと assume-unchanged を実行することでしょうか?なぜ、ある方法を好むのでしょうか? なぜなのでしょうか?

  3. 私の基本的な使用例では、コンパイルされたファイルの差分をソートするのを避けたいのですが、それでもコンパイルされたファイルを同期させたいのです。 しかし、ソースファイルと一緒にコンパイルされたファイルを同期させたいのです。 をソース ファイルと同期させたいということです。このような場合 gitignore d ファイルはまだプッシュされますか?そうでない場合、コンパイルされたファイルの最終的なデプロイメントをどのように管理するのですか?

どのようなヘルプでも事前に感謝します。

どのように解決するのですか?

私は 浜野純夫氏からのメールによる回答 (Gitのメンテナ)からのメールでの回答は、公式のドキュメントよりも分かりやすく説明されており、公式のアドバイスとして受け取ることができると思いますので、これを受け入れます。

.gitignoreと.git/info/excludeは、同じメカニズムを呼び出すための2つのUIです。 同じメカニズムです。 ツリー内の.gitignoreは、プロジェクトのメンバー間で共有されます。 プロジェクトのメンバー間で共有されます (つまり、そのプロジェクトで作業している全員が、無視パターンにマッチするパスを.gitignore に含める必要があります)。 はプロジェクトのメンバー間で共有されます(つまり、プロジェクトに参加している全員が、無視パターンにマッチするパスを残骸と見なすことになります)。 一方 一方、.git/info/exclude は個人的な無視パターンのためのものです(つまり、プロジェクトで作業しているあなたが、その無視パターンにマッチするパスをつまらないものとみなすということです)。 プロジェクトで作業している間、あなたはそれらを残骸と見なします)。

Assume-unchangedは無視のメカニズムとして乱用されるべきではありません。 それは "私のファイルシステム操作が遅いのは知っています。 私はGitに約束します。 このビットを使ってこれらのパスを変更しないことをGitに約束しよう---そうすれば、Gitは私がそこにあるものを変更したかどうかをチェックする必要がなくなる。 に問い合わせるたびに、パスを変更したかどうかをチェックする必要はありません。 を要求するたびに、Gitはその中にあるものを変更したかどうかをチェックする必要がなくなります。 それ以外の意味はありません。 特に、それは ではなく を常に考慮するというGitの約束ではありません。 としてマークされたパスが変更されたと Git が判断できる場合、余分なコストをかけずに変更されたと判断できます。 とマークされたパスが変更されたとGitが判断した場合、余分な lstat(2)のコストをかけずに変更されたと判断できる場合、Gitはそのパスが変更されていないと報告する権利を有します。 が変更されたと報告する権利を有します。 が変更されたと報告する権利を留保します(その結果、"git commit -a" はその変更をコミットする自由を得ます)。