「git reset」と「git checkout」の違いは何ですか？

私はいつも考えてきたgit resetとgit checkoutの両方の特定のコミットにプロジェクトのバックを持っているという意味で、同じよう。ただし、冗長になるため、完全に同じにすることはできません。2つの実際の違いは何ですか？svn svn coはコミットを元に戻すだけでよいので、少し混乱しています。

追加された

VonCとCharlesは、との違いgit resetをgit checkout非常によく説明しました。私が現在理解しているのは、git resetすべての変更を特定のコミットに戻すことgit checkoutですが、ブランチの準備は多かれ少なかれ行っています。この理解を深めるには、次の2つの図が非常に役立つことがわかりました。

追加3

http://think-like-a-git.net/sections/rebase-from-the-ground-up/using-git-cherry-pick-to-simulate-git-rebase.htmlから、チェックアウトとリセットでエミュレートできますリベース。

git checkout bar 
git reset --hard newbar 
git branch -d newbar 

• git reset具体的には、インデックスの更新、HEADの移動についてです。
• git checkoutです作業ツリーを更新（インデックスまたは指定されたツリーに）。ブランチをチェックアウトした場合にのみHEADを更新します（そうでない場合、デタッチされたHEADになります）。
  （実際には、Git 2.23 2019年第3四半期では、これはgit restore、必ずというわけではありませんgit checkout）

比較すると、svnにはインデックスがないため、作業ツリーのみsvn checkoutが、特定のリビジョンを別のディレクトリにコピーします。
のより近い同等物git checkoutは：

• svn update （同じブランチにいる場合、つまり同じSVN URLを意味します）
• svn switch （たとえば、同じブランチであるが、別のSVNリポジトリURLからチェックアウトする場合）

すべてのこれらの3つの作業ツリーの変更（svn checkout、update、switch）のgitに一つだけのコマンドがありますgit checkout。
しかし、gitにはインデックス（リポジトリと作業ツリーの間の「ステージング領域」）の概念もあるので、も持っていgit resetます。

Thinkeyeはコメントの中で記事「リセットされた謎解き」について言及しています。

たとえば、異なるコミットを指す' master'と ' develop'の2つのブランチがあり、現在 ' develop'にいる（したがってHEADがそれを指している）場合、実行するとgit reset master、 ' develop'自体が同じコミットを指すようになります ' master'します。

一方、代わりにを実行するとgit checkout master、 ' develop'は移動せず、HEADそれ自体が移動します。HEAD' master'を指すようになります。

したがって、どちらの場合もHEAD、コミットを指すように移動しますAが、その方法は大きく異なります。reset分岐HEAD点に移動し、チェックアウトはHEAD別の分岐を指すように移動します。

ただし、これらの点について：

LarsHはコメントに追加します：

ただし、この回答の最初の段落は誤解を招くものです。「git checkout...ブランチをチェックアウトした場合にのみHEADを更新します（そうでない場合、分離したHEADになります）」。
真でgit checkoutはありません：ブランチではないコミットをチェックアウトした場合でもHEADを更新します（はい、デタッチされたHEADになりますが、それでも更新されます）。

git checkout a839e8f updates HEAD to point to commit a839e8f.

De Novoはコメントに同意します：

@LarsHは正しいです。
2番目の箇条書きは、ブランチをチェックアウトした場合にのみ、HEADの内容がHEADを更新するという誤解を持っています。
HEADはどこにいても影のように移動します。
ブランチ以外の参照（タグなど）またはコミットを直接チェックアウトすると、HEADが移動します。デタッチされたヘッドは、HEADからデタッチされたことを意味するのではなく、ヘッドがブランチ参照からデタッチされたことを意味しますgit log --pretty=format:"%d" -1。

• 取り付けられたヘッド状態が始まります(HEAD ->、
• detachedは引き続き表示されますが(HEAD、ブランチ参照への矢印はありません。

最も単純な形式でresetは、作業ツリーに触れずにインデックスをリセットし、インデックスに触れずに作業ツリーをcheckout変更します。

インデックスをmatchにリセットしHEAD、作業ツリーをそのままにします。

git reset

概念的には、これは作業ツリーへのインデックスをチェックアウトします。実際に何かを実行させるには-f、ローカルの変更を強制的に上書きするために使用する必要があります。これは、「引数なし」フォームが破壊的でないことを確認するための安全機能です。

git checkout

パラメータの追加を開始すると、いくつかの重複があることは事実です。

checkout通常、ブランチ、タグ、またはコミットで使用されます。この場合HEAD、インデックスがリセットされて指定されたコミットになり、作業ツリーへのインデックスのチェックアウトが実行されます。

また、あなたが提供する場合--hardにresetご依頼することができreset、インデックスをリセットするだけでなく、作業ツリーを上書きします。

現在ブランチをチェックアウトしている場合、別のブランチまたはコミットを提供する場合と提供する場合との間には決定的な違いがresetありcheckoutます。reset選択したコミットを指すように現在のブランチを変更しますが、現在のブランチcheckoutはそのままにしますが、代わりに提供されたブランチをチェックアウトまたはコミットします。

その他の形式resetおよびcommit供給経路が含まれます。

あなたにパスを供給した場合reset、あなたを供給することはできません--hardとresetだけコミット（または供給にバージョンに供給されたパスのインデックスバージョンを変更しますHEAD、あなたがコミットを指定しない場合）。

あなたはへのパスを指定した場合checkoutと同様に、resetそれは供給コミット（または一致に供給されたパスのインデックスバージョンに更新されますHEAD）を、それは常に作業ツリー内に供給されたパスのインデックスバージョンをチェックアウトします。

変更を元に戻す場合の1つの簡単な使用例：
1.変更されたファイルのステージングを元に戻す場合は、リセットを使用します。
2.ステージングされていないファイルへの変更を破棄する場合は、チェックアウトを使用します。

一言で言えば重要な違いは、あるreset 移動現在の分岐参照しながら、checkoutしない（それはヘッドを移動します）。

Pro Gitの本で「Demystifiedのリセット」で説明されているように、

最初resetに行うことは、HEADが指すものを移動することです。これはHEAD自体を変更することと同じではありません（これは何をするかcheckoutです）。HEADが指してreset いるブランチを移動します。つまり、HEADがmasterブランチに設定されている場合（つまり、現在masterブランチにいる場合）は、git reset 9e5e6a4をmasterポイントすることで実行が開始され 9e5e6a4ます。【強調追加】

同じ記事からの非常に役立つテキストと図の抜粋については、VonCの回答も参照してください。ここでは重複しません。

もちろん、使用されるパラメーターに応じて、インデックスと作業ツリーにどのような影響がcheckoutあり、どのような影響を与えるreset可能性があるかについて、より多くの詳細があります。2つのコマンドには多くの類似点と相違点があります。しかし、私が見ているように、最も重要な違いは、彼らが現在の枝の先端を動かすかどうかです。

2つのコマンド（リセットとチェックアウト）は完全に異なります。

checkout X ではありません reset --hard X

Xがブランチ名の場合 checkout X、現在のブランチは変更されますが、変更reset --hard Xされません。

簡単なニーモニック：

git reset HEAD           :             index = HEAD
git checkout             : file_tree = index
git reset --hard HEAD    : file_tree = index = HEAD