6

誤っ.idea/workspace.xmlてrubymineによって作成されたファイルを追跡しましたが、追跡からファイルを削除できないようです。

このため、何度もチェックインされていますが、マージの競合が発生するため、追跡を停止したいと思います。

これが私がファイルを削除しようとし続ける方法です。

  1. git rm --cached .idea/workspace.xml

    $ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

deleted:    .idea/workspace.xml

  2. git commit -m 'remove workspace file from tracking'

  3. このエントリを.gitignoreファイルに追加します.idea/*
4

3 に答える 3

0

あなたが示したものはうまくいくはずです。ファイルが繰り返し再導入される可能性のある方法が 2 つあります。

  • 他の誰かがまだマージ エラーを受け取り、変更を追加して削除を無視することで解決している場合、ファイルは戻ってきます。

  • リポジトリに含めていない.gitignoreか、.gitignore への追加をコミットしていない場合.ideas/*、他の人が次のような方法でファイルを再追加している可能性があります。

    git add -a

    また

    git add .

    これが起こらないようにするには、変更を .gitignore にコミットする必要があります。

于 2012-12-07T16:31:14.320 に答える
0

ファイルがコミットされたら、それを無視するように git に指示する 2 つの方法があります。

  1. ファイルの削除をコミットしてから、.gitignore

    git rm --cached git commit -m "削除されました..."

  2. フラグassume-unchangedを立てる

--[no-]assume-unchanged

このフラグを指定すると、パスに記録されたオブジェクト名は更新されません。
代わりに、このオプションは、パスの「変更されていないと仮定する」ビットを設定/設定解除します。

「変更されていないと仮定する」ビットがオンの場合、ユーザーはファイルを変更しないことを約束し、作業ツリー ファイルがインデックスに記録されているものと一致すると Git が想定できるようにします。作業ツリー ファイルを変更する場合は、ビットを設定解除して Git に通知する必要があります。これは、lstat(2) システム コールが非常に遅いファイル システム (cifs など) で大きなプロジェクトを扱う場合に役立つことがあります。

コミットでマージする場合など、インデックス内のこのファイルを変更する必要がある場合、Git は (正常に) 失敗します。したがって、想定されていない追跡対象ファイルが上流で変更された場合は、手動で状況を処理する必要があります。

于 2016-04-17T21:30:00.260 に答える