343

git revertファイルとプロジェクトを以前の状態に復元またはロールバックする方法を学習しようとしていますが、、、、checkoutの違いがわかりませんreset。一見同じ目的のために3つの異なるコマンドがあるのはなぜですか？また、誰かがどちらかを選択する必要があるのはいつですか？

4

7 に答える 7

542

これらの3つのコマンドの目的はまったく異なります。それらはリモートでさえ類似していません。

git revert

このコマンドは、前のコミットからの変更を元に戻す新しいコミットを作成します。このコマンドは、プロジェクトに新しい履歴を追加します（既存の履歴は変更しません）。

git checkout

このコマンドは、リポジトリからコンテンツをチェックアウトし、それを作業ツリーに配置します。コマンドがどのように呼び出されたかによっては、他の影響もあります。たとえば、現在作業しているブランチを変更することもできます。このコマンドは履歴に変更を加えません。

git reset

このコマンドはもう少し複雑です。実際には、呼び出される方法に応じて、いくつかの異なることを行います。インデックス（いわゆる「ステージング領域」）を変更します。または、ブランチヘッドが現在指しているコミットを変更します。このコマンドは、既存の履歴を変更する場合があります（ブランチが参照するコミットを変更することにより）。

これらのコマンドの使用

プロジェクトの履歴のどこかでコミットが行われ、後でコミットが間違っていて実行されるべきではないと判断した場合は、それgit revertがそのジョブのツールです。不正なコミットによって導入された変更を元に戻し、履歴に「元に戻す」を記録します。

作業ツリー内のファイルを変更したが、変更をコミットしていない場合は、を使用git checkoutして、ファイルのリポジトリからのフレッシュコピーをチェックアウトできます。

コミットしたが、他の人と共有しておらず、それを望まないと判断した場合はgit reset、履歴を書き換えて、コミットしたことがないように見せることができます。

これらは、考えられる使用シナリオのほんの一部です。状況によっては役立つ他のコマンドがあり、上記の3つのコマンドには他の用途もあります。

于 2011-12-02T14:43:33.850 に答える
85

コミットしたとしましょう：

C
B
A

git revert B、の変更を元に戻すコミットを作成しますB。

git revert A、の変更を元に戻すコミットを作成しますが、の変更にAは触れませんB

Bの変更がの変更に依存している場合A、の元に戻すことはできないことに注意してくださいA。

git reset --soft A、コミット履歴とリポジトリを変更します。ステージングおよび作業ディレクトリは、引き続きの状態になりCます。

git reset --mixed A、コミット履歴、リポジトリ、およびステージングを変更します。作業ディレクトリはまだの状態のままですC。

git reset --hard A、コミット履歴、リポジトリ、ステージング、および作業ディレクトリを変更します。完全に状態に戻りますA。

于 2017-07-15T16:03:08.030 に答える
30
  • git revert前のコミットを元に戻すために使用されます。gitでは、以前のコミットを変更または消去することはできません。（実際には可能ですが、問題が発生する可能性があります。）したがって、revertは、以前のコミットを編集する代わりに、以前のコミットを逆にする新しいコミットを導入します。
  • git resetまだコミットされていない作業ディレクトリの変更を元に戻すために使用されます。
  • git checkout他のコミットから現在の作業ツリーにファイルをコピーするために使用されます。ファイルを自動的にコミットしません。
于 2011-12-02T14:40:43.560 に答える
25
  • git checkout作業ツリーを変更し、
  • git reset使用しているブランチがポイントしている参照を変更します。
  • git revert変更を元に戻すコミットを追加します。
于 2011-12-02T14:20:18.523 に答える
7

リセット- コミットレベルでは、リセットはブランチの先端を別のコミットに移動する方法です。これは、現在のブランチからコミットを削除するために使用できます。

元に戻す-元に戻す と、新しいコミットを作成してコミットを元に戻します。コミット履歴を書き換える可能性がないため、これは変更を元に戻すための安全な方法です。これをgitresetと比較してください。これにより、既存のコミット履歴が変更されます。このため、パブリックブランチでの変更を元に戻すにはgit revertを使用し、プライベートブランチでの変更を元に戻すにはgitresetを予約する必要があります。

あなたはこのリンクを見ることができます -リセット、チェックアウト、そして元に戻す

于 2015-11-18T10:06:12.640 に答える
6

ツリーを壊したがコードをコミットしなかった場合は、を使用git resetできます。1つのファイルを復元したい場合は、を使用できますgit checkout。

ツリーを壊してコードをコミットした場合は、を使用できますgit revert HEAD。

http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html

于 2011-12-02T14:16:53.367 に答える
3

git restore質問に追加して答えてみます

次のコミット履歴があるとします。

D
C
B
A

git revert：

リバースコミットを行います。git revert commit-hashコミット履歴は変更されませんが、コミットの一部としてコミットされた変更を元に戻す新しいコミットを作成します

git revert B、の変更を元に戻すコミットを作成しますB。Gitの履歴ポストイット

reverse-B
D
C
B
A

コミットがコミットCに依存している場合B git revert B、マージ競合が発生します

提案：git revertパブリックコミットを元に戻すように設計されています。変更を元に戻す他のすべての方法は、プロジェクトの他の参加者に問題を引き起こす可能性のあるコミット履歴を変更する可能性があります。git revertコミット履歴に干渉することなく変更を元に戻す方法です

git restore：

git restoreファイルをcommit/staging-areaからworktree/staging-areaに移動するのに役立ちます

コマンドはgitrestore[--source = commit-hash] [--worktree] [--staged][-]fileです。

  • --worktreeは、worktreeに復元することを意味します
  • --stagedは、-stagedに復元することを意味します。
  • --stagedと--worktreeの両方を指定して、-sourceからworktreeとstaging-areaの両方に復元します。
  • --sourceが指定されている場合、復元は常にソースから行われます
  • --sourceが指定されておらず、-stagedが指定されている場合、復元はHEADから行われます。
  • --sourceも--stagedも指定されていない場合、復元はステージング領域からワークツリーに行われます。

提案-git restoreからファイルを持ってくるために使用します

  • BLOBをステージングエリアやワークツリーにコミットします。
  • ステージングエリアからワークツリーへ

git checkout commit-hash：

git checkoutファイルをコミットからステージング領域またはワークツリーにプルするのに役立つファイルレベルの実装がありますがgit restore、これはコマンドの責任であり、整理して作成するように正確に設計されているため、ここでは説明しません。git checkoutコマンドの一貫性。

  • git checkout commit-hash-ヘッドが移動してcommit-hashをポイントします。常に頭を切り離した状態にしておきます。
  • git checkout branch-ヘッドが移動して指定されたブランチを指すようになり、これは切り離された状態ではなくなりました

提案：git checkoutツリーの周りのさまざまなコミットを確認し、ブランチを切り替えるために使用します

git reset commit-hash：

  • あなたは切り離された頭の状態にありました-指定されたにgit reset移動HEADしますcommit-hash。と同じようにgit checkout commit-hash
  • ヘッドが切り離された状態ではありませんでした-git reset全体(HEAD -> branch)を指定されたに移動しますcommit-hash。その結果、commits先行するブランチがない場合、それらのコミットはgit履歴から削除されます

git resetまた、3つのオプション、、、があり--softます。別のコミットに移動した後、ワークツリーとインデックス（ステージング領域）はどのようになりますか？--mixed--hardHEAD

  • --hard-ワークツリーとインデックスの両方が、移動先の新しいコミットのファイルと一致します
  • --mixed（デフォルト）-ワークツリーは実行前の状態のままでgit resetあり、インデックスは移動先の新しいコミット内のファイルと一致します
  • --soft-ワークツリーとインデックスはどちらも、実行前の状態のままですgit reset

git resetgit checkoutほとんどの場合、の組み合わせを使用して複製できます。ただし、git resetを使用しない場合git branch -Dをgit restore除いて、worktreeとstagin-areaのコンテンツを制御する簡単な方法はありません。

提案：行われるべきではなく、公開リポジトリに変更をプッシュしていないコミットをいくつか行ったことがありますか？これらのコミットが存在しなかったかのように持つのが最善ですか？を使用しgit resetます。変更をパブリックリポジトリにプッシュした場合は、前に説明したように、git revert

于 2021-07-10T06:58:03.660 に答える