60

git リポジトリに、ローカルで変更されたファイルがあります。私はgitにローカルの変更を永久に無視させたいのですが、ファイルは無視したいと思っています。特に、

  • この変更以外にファイルが変更されていない場合は、git add .決してステージングしないでください。
  • 同様に、git commit -aコミットしないでください。
  • ファイルに追加の変更を加えた場合、その変更をステージングしてコミットできるはずですが、無視している変更はステージングしてコミットするべきではありません。

これを行う方法はありますか？いくつかの調査を行って、「汚れ/きれいなサイクル」について読みました。ここで、正しく読めば、

  1. ファイルは未変更としてマークされます。
  2. 行った変更は、チェックアウト時に上書きされます。
  3. その後、スクリプトは自動的に変更を再適用し、ファイルを未変更として再度マークします。

私は git とスクリプティングに非常に慣れていませんが (私は C# と Java の経験を持つインターンです)、それが必要な場合は、詳細な指示またはスマッジの設定方法に関するチュートリアルへのリンクを投稿してください。 /クリーンサイクルアップ?

背景:作業ブランチがトランクと同期しないようにしたいです。開発マシンにのみ影響する優先度の低いバグがあるため、修正するのではなく、問題のあるコードをコメントアウトするだけです。明らかに、このコードが問題なく動作する本番環境から削除されることは望ましくありません。

4

9 に答える 9

54

ビットが使えskip-worktreeます。次の方法でオンにします。

git update-index --skip-worktree <file>

その後、git はローカルの変更をステージングすることはなく<file>、git 自体に書き込む必要がある場合<file>(マージやチェックアウトなど) は (大きな音で) 失敗します。

将来の変更をステージングしたい場合は、それをオフにし、新しい変更をステージングしてから、オンに戻すことができます。

git update-index --no-skip-worktree <file>
git add -p <file>
git update-index --skip-worktree <file>

完璧ではありませんが、これで十分かもしれません。ステージングされていない変更があることに気付くのはあなた次第です<file>.gitはもはやそれを教えてくれません.

注:私の最初の提案は、 を使用することでしたassume-unchanged。Git - Difference Between 'assume-unchanged' and 'skip-worktree'で説明されているように、それは本当にskip-worktreeあなたが望むものです。特に、assume-unchangedファイルを変更しないという Git への約束であり、その約束に違反した場合、Git は変更を消去するかコミットすることができます。対照的に、Git はskip-worktree変更を消去またはコミットしません。

于 2013-05-17T04:14:21.760 に答える
22

これらの回答は適切ですが、@Kevin の問題を最適に解決できない可能性があります。私も同様の懸念を抱いていました。多くの場合、構成ファイルを編集して、作業中のアプリが実稼働データベースではなく独自の開発データベースにアクセスするようにしました。誤ってチェックインして、これらの構成変更をプッシュするのは時間の問題です! ファイルを無視するための軽量な方法が必要でした。これが私が学んだことです：

  • まず、ファイルに必要な変更を加えます。私はそれを呼びますmy_config。

  • その変更のパッチファイルを作成しますgit diff >../somewhere-else/my_config.patch

  • 次に、そのファイルを無視するように git に指示します (チェックインされた .gitignore を変更する必要はありません)。git update-index --assume-unchanged my_config

これで、チェックインしたいものを変更しない限り、自由に作業できmy_configます。無視をやめるには、 を実行します。他の人の変更を に取り込んだ後、 を使用して個人的な変更を簡単に復元できます。次に、上記のように、再び変更を想定せずに、作業に戻ることができます。my_configgit update-index --no-assume-unchanged my_configmy_configgit apply ../somewhere-else/my_config.patch

に入れることができる便利なエイリアスを次に示します~/.gitconfig。

[alias]
    unchanged = update-index --assume-unchanged
    changed = update-index --no-assume-unchanged
    show-unchanged = !"git ls-files -v | sed -e 's/^[a-z] //p; d'"
于 2018-03-19T18:30:00.613 に答える
1

はい、これはおそらく汚れ/きれいなフィルターを使用して行うことができます. ただし、これはかなり複雑でエラーが発生しやすいため、これを行うことは強くお勧めしません (たとえば、git で構築されている多くのツールを混乱させたり、デバッグが困難になるなど)。

また、一般的に、永続的なローカル変更を行うことはお勧めできません。SCM を使用する際の重要なポイントの 1 つは、バージョンをチェックアウトしてすぐに機能させることができることです。つまり、必要なものはすべてチェックインする必要があります。

git でもおそらく他のほとんどの SCM でも、これを行うための「良い」方法はないと思います。要件を再考することをお勧めします。

問題は、「混合コンテンツ」を含むファイルがあるようです。常に同じコンテンツと、ローカルで変更する必要があるコンテンツ (マシン固有のオプション?) があります。これを処理するための推奨される方法は、問題のあるファイルをチェックインするのではなく、代わりに「テンプレート」ファイルをチェックインし、ビルド時に実際のファイルを生成することです。これを調べてみてください。今は (おそらく) より多くの作業が必要になりますが、より多くのバリエーションをサポートする必要がある場合や、他の人が同じプロジェクトに取り組みたい場合は特に、作業が簡単になります。

編集（コメントの情報に基づく）

開発マシンにのみ必要で、本番環境では必要ないローカル コードの変更を無視したいと書いています。

その場合、コメントアウトする代わりに、何らかの条件でコードをラップして、開発マシンでのみ実行されるようにします (たとえば、条件付きコンパイルを使用するか、構成ファイルまたは何らかの環境プロパティを読み取るか、または ...(1 )))。その後、通常どおりコードをチェックインできます。

さらに良いことに、バグを修正するだけです。バグが開発を困難にする場合、私見では優先度が高いです。

コードをコメントアウトするだけではお勧めできません。これはエラーが発生しやすく、チェックアウトするたびに実行する必要があります。とりわけ、開発環境と本番環境で異なるコードを実行することはトラブルの原因となるため、可能な限り回避する必要があります。

(1) 例として: 当社では、このような場合に特化した環境変数を用意しています。これは、コードが開発中、ベータ テスト中、または運用中のいずれで実行されているかを示し、ビルドおよびデプロイ スクリプトによって設定されます。ただし、通常は、異なるファイル パスを選択するなどの単純なことにのみ使用されます。上記で説明したように、環境に基づいてプログラム ロジックを変更することは推奨されません。

于 2013-05-17T07:37:03.113 に答える
0

私が見ているように、あなたが説明している状況は次のとおりです。ローカルリポジトリとは異なる作業ディレクトリを維持したいと考えています。

これはお勧めできません。これらの変更はコミットされていないため、ファイルが誤って削除されたり、望ましくない方法で変更されたりした場合、ほとんど頼りになりません。

したがって、実際にすべての変更をコミットすることをお勧めします。これらの変更を分離したい場合は、ブランチを使用して簡単に行うことができます。例

git checkout -b new-branch
# now you can change the file without affecting master
echo bar >> foo
git add
git commit
# and back to master
git checkout master
于 2013-05-17T03:57:48.527 に答える