偶発的なチェックアウト後に変更を取り戻しますか？
以下は私のレポのステータスでした。
[~/Rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ gst
# On branch design
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: _layouts/default.html
# deleted: _site/blog/2010/04/07/welcome-to-niraj-blog/index.html
# deleted: _site/blog/2010/04/08/the-code-syntax-highlight/index.html
# deleted: _site/blog/2010/05/01/showing-demo-to-kalyan/index.html
# deleted: _site/config.ru
# deleted: _site/index.html
# deleted: _site/static/css/style.css
# deleted: _site/static/css/syntax.css
# modified: static/css/style.css
#
no changes added to commit (use "git add" and/or "git commit -a")
したがって、私はgit checkout -fそして今、私が行うことになっていない変更がなくなっています。
[~/Rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ git co -f
[~/Rails_apps/jekyll_apps/nepalonrails (design)] ➔ gst
# On branch design
nothing to commit (working directory clean)
[~/Rails_apps/jekyll_apps/nepalonrails (design)] ➔
変更を元に戻すことはできますか？
現在の作業ディレクトリに他のバックアッププロセスが用意されていない限り、これらのプライベートデータ（「インデックスに追加されていない、コミットされていない」などのgitでは不明な「プライベート」）を回復できないと思います。
これがGitエイリアスページで提案されていない場合でも、チェックアウトのために何らかのエイリアスを主張します（ alias rm /bin/rm -i使用法）：
[alias]
co = !sh -c 'git stash; git stash apply; git checkout "$@"'
、 Brian Campbell in his answer で使用される「チェックポイント手法」である「git stash; git stash apply」.
co = "!git stash Push -m \"co backup\"; git stash apply; git checkout \"$@\""
注：バックアップスタッシュを他のユーザーに知らせるメッセージを追加しました。 –
この問題は、 ycombinator （extracts）でのこの動作に関する議論を思い出させます：
Gitで大量のデータを失いました。
そのほとんどは、データを削除するときに確認を求めない無害な発音のコマンドに関係しています。
たとえば、git checkout filenameはsvn revert filenameと同等です。
もちろんgit checkout branchnameはまったく異なることを行います。
ブランチとファイルが同じ名前を共有している場合、gitはデフォルトでブランチを切り替えますが、bashオートコンプリートがその日を台無しにすることを止めません。クレイジーなアイデアは次のとおりです。無害なアクションと危険なアクションがある場合は、同じコマンドでラベル付けしないでください。
迷惑かもしれませんが、これはユーザーエラーであり、設計エラーではありません。 gitを使用して、作業コピーを無損失で破棄する場合は、「
git stash」だけで済みます。
ロジックでは、-fの代わりに-iを渡すときに確認を求めないため、「rm」に欠陥があります。まあ、そうだろう。ごめんなさい。
rm somenameがapt-get updateと同等で、rm othernameがrm -fr othernameである場合、類推はより正確になります。
それでも、 "get checkout foo"が現在のディレクトリにfooというファイルがあるかどうかに応じて、2つの完全に異なることのいずれかを行うのは正しくありません
もう1つのおかしなアイデアがあります。「
git checkout ...」をダーティワークツリーで実行しないでください。問題が解決しました。
別の方法：ファイル名をブランチ名として再利用しないでください。
正直に言うと、「rm」の不注意な呼び出しで同じ問題を抱えていますが、呪いをつぶやいているときは、怠ash /愚かさであり、bashの完了や'rm'の動作
もう1つ確認できるのは、IDEを使用することです。私は誤って2つのファイルをチェックアウトし、私のIDE（netbeans）の「ローカル履歴」を通じて変更を取り戻すことができました。なんて素晴らしいことでしょう！
以前にこれらのファイルでgit addまたはgit stashを使用したことがない限り、残念ながらいいえ。追加またはスタッシュした場合は、 git reflog でハッシュを見つけることができます。
私はgit checkoutのこの破壊的な振る舞いに決して満足していません。おそらく、便利な拡張機能は、作業を上書きする前に、この種のgit checkoutが自動的にスタッシュを作成して（reflogを介してファイルがキャプチャされるようにする）ことです。
Linuxでvimを使用している場合、以下が適用される場合があります。
ファイルがアクティブなバッファで開かれている場合、vimでファイルをリロードしない限り、ファイルの内容を取得し、保存して復元できます。 。
ファイルがアクティブなバッファーで開かれていないが汚れている場合、ソースディレクトリに.swpファイルがあり、
vim -r file.swpを介して回復可能なコンテンツのコピーも必要です。ファイルが非アクティブバッファでもダーティでも開かれておらず、作業コピーがext3またはext4パーティション上にある場合、 extundelete は最近削除された.swpファイルや古いファイルを見つけることができる場合がありますソースファイルのバージョン。パーティションを読み取り専用として再マウントします。
mount -o remount,ro /mnt/point、および実行extundelete --recover-directory /path/to/working/copy /dev/sdaX作業コピーを含むパーティションがルートパーティションである場合、再マウントを拒否して、すべてのサービスを強制終了し、まだ実行されない場合は、ライブCD/USB/PXEを使用して [ 〜＃〜] grml [〜＃〜] で、上記を実行します。この方法で、3つの失われたファイルのうち1つを回復することに成功しました。
Eclipse as IDEおよびEGitを使用する場合、ファイルにチームメニューがあります。
- 内からファイルを右クリックします
- リスト項目「チーム」->「ローカル履歴を表示」
私の場合、保存名なしですべてのバージョンがローカルに保存されますが、git機能から追跡されていないすべての変更を簡単にチェックし、不足しているコードを復元できます。
IDE is Android Studioの場合、変更されたファイルを開き、VCS-> Local History-> Show Historyに移動します。開いたファイルが表示されます。 。
Gitコマンドでできることは何もありませんが、IDEを使用している場合は、変更を回復できます。PhpStormを使用して、ファイルの変更履歴を確認できます。 [ローカルの履歴を表示]をクリックします[外部の変更]タブで、誤って削除したローカルの変更を見つけることができます。
IDEを使用し、元に戻すオプションがある場合、変更を元に戻すと、ディスクからのリロードが元に戻り、変更が元に戻ります。ほとんどのIDE /エディターにはこのオプションがあります。
Intellijを使用しています。 CTRL + z 私のために働く、それはあなたが「ディスクから変更をリロードする」プロンプトを表示し、はいを押します。