37 
git mv file1 file2

git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   renamed:    file1 -> file2

git stash
git stash pop

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   file2
#
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    file1

ご覧のとおり、git は stash / pop の後に名前が変更された関係を失います。この関係を回復する方法、またはファイルが移動されたことを stash に知らせる方法はありますか? 変更前のシステム状態を確認するために隠しておくことがよくありますが、名前変更の関係が失われることは私にとって問題です。新しいファイルを削除し、もう一度 git mv を実行し、新しいファイルの内容を置き換える以外に修正する方法がわかりません。

4

2 に答える 2

48

まだスタッシュをポップしていない場合は、次のようにします。

git stash pop --index

これにより、移動された (ただしコミットされていない) ファイルの関係がスタッシュに正しく保存されます。によるとgit help stash：

--index オプションを使用すると、作業ツリーの変更だけでなく、インデックスの変更も元に戻そうとします。ただし、これは競合がある場合に失敗する可能性があります (競合はインデックスに格納されているため、元のように変更を適用できなくなります)。

すでにスタッシュをポップしており、移動した関係を再作成したい場合は、次のようにします。

git rm --cached file1

これにより、移動されていない「古い」ファイルがインデックスから削除されます。

このオプションを使用して、パスのみをインデックスからステージング解除して削除します

于 2011-12-13T21:04:05.363 に答える
21

簡潔な答え：git rm --cached file1

実際に行うことは、(ファイルシステム上で) ファイルのgit mv名前を変更してから、ファイルの削除と作成をインデックス (ステージング領域) に追加することだけです。特に表記はありません。その後、他の機構は、以前に file1 と呼ばれていたコンテンツが file2 と呼ばれるようになったことを確認することで、それが名前変更であったことを認識します。

git stashコマンドはインデックスを変更するため、混乱を招く可能性があります。これで、作成はステージングされましたが、削除はされていないことに注意してください。(通常、git-stash は pop の後にすべてをステージングしないままにしますが、この場合、新しいファイルをインデックスに配置する以外に選択肢はあまりないと思います。これにより、どれを保持するかがわからないのを避けることができます。これを回避できます。でgit stash pop --index発生することはありますが、隠した変更をきれいに適用できない場合は爆発するため、デフォルトではありません。git status名前変更はインデックスと作業ツリーの間で効果的に分割されるため、名前変更として表示することはできません。そして、どちらのセクションもそれを完全に主張することはできません。

単に実行git rm --cached file1して削除をステージングする (つまり、インデックスから file1 を削除する) と、名前の変更として再び表示されます。git add -uステージングしたくない変更が他にない限り、変更を自動的に追加するために実行することもできます。

これは、実際には心配する必要がないことを意味することに注意してください。コミットの準備ですべてを適切にステージングすると (たとえば、 を使用git add -u)、「問題」は自然に解決します。

于 2011-12-13T20:05:43.797 に答える