回答:
git checkout 'master@{7 days ago}' -- path/to/file.txt
これはHEADを変更せず、ローカルファイルを上書きするだけです。 path/to/file.txt
そこで可能なリビジョン仕様については、man git-rev-parseを参照してください(もちろん、(のようなdd9bacb
)単純なハッシュはうまく機能します)
変更をコミットすることを忘れないでください(レビュー後...)
revision-specification
ですが、OPが尋ねたので、たまたま「複雑な」例を示しました:)
shacommit~1
(ex:)を使用してgit checkout 0f4bbdcd~1 -- path/to/file.txt
直前にコミットを取得します。
git checkout [Revision_Key] -- path/to/file
。git checkout
単一のファイルを処理でき(seheによる回答を参照)、コピーして貼り付ける必要はありません。
HEAD
、ORIG_HEAD
またはと組み合わせたもののいずれか^
/ ~
/ @
スタイルの表記。
gitにコミットされた最近のファイルを復元する必要がありました。繰り返しますが、別の視点を与えるには、次の2つのステップを実行してこれを行う必要があります。
git log -3
これは、最新の3つのコミットを示しています。コメントと作成者の名前を読んで、希望する正確なバージョンを絞り込みます。必要なコミットバージョンの長いコミットID(b6b94f2c19c456336d60b9409fb1e373036d3d71)を書き留めます。
git checkout b6b94f2c19c456336d60b9409fb1e373036d3d71-myfile.java
コミットするIDと復元するファイル名を渡します。二重ハイフンの前後にスペースがあることを確認してください。
それを行うには他にも多くの方法があります。しかし、これは私が覚えているより簡単なものです。お役に立てば幸いです。
注:プロジェクトのパス/フォルダー内にいる場合は、チェックアウトコマンドで完全なファイルのパスを入力する必要はありません。
すべての回答は言及していgit checkout <tree-ish> -- <pathspec>
ます。git v2.23.0以降、新しいgit復元メソッドがあり、これgit checkout
が原因の一部と見なされることになっています。githubブログで変更点のハイライトをご覧ください。
このコマンドのデフォルトの動作は、source
パラメーター(この場合はコミットハッシュ)からのコンテンツで作業ツリーの状態を復元することです。
commitハッシュを想定すると、abcdef
コマンドは次のようになります。
git restore --source=abcdef file_name
(デフォルトで)作業ツリーに配置します。変更を直接インデックスに入れて、すぐにコミットできるようにする場合:
git restore --source=abcdef --worktree --staged file_name
または短いオプション名:
git restore -s=abcdef -W -S file_name