Is there a difference between "git reset - hard hash" and "git hash check"?

Question

While reset and checkout have different ways of using most of the time, I don't see what the difference is between the two.

Probably one or no one would want to add the --hard option to do what a basic checkout can do.

Maybe there is a difference in how you see the story?

Answer 1

This answer is mostly quoted from my answer to the previous question: git reset in English .

Both of them are very different. They lead to the same state for your index and work tree, but the resulting history and the current branch do not match.

Suppose your story looks like this: with a verified leading branch:

 - A - B - C (HEAD, master) 

and you run git reset --hard B You will receive the following:

 - A - B (HEAD, master) # - C is still here, but there no # branch pointing to it anymore 

In fact, you will get this effect if you also use --mixed or --soft - the only difference is what happens to your tree and index. In the case of --hard , the work tree and index correspond to B

Now suppose you run git checkout B You will receive the following:

 - A - B (HEAD) - C (master) 

You are in a separate HEAD state. HEAD , work tree, index match B , same as hard reset, but the main branch remained in C If you make a new D commit at this point, you will get this, which is probably not what you want:

 - A - B - C (master) \ D (HEAD) 

So you use checkout to check it out. You can play with him, do what you like, but you left your branch behind. If you want the branch to move, you use reset.

Answer 2

If the documentation provided with Git does not help you, take a look at Mark Lodato's A Visual Git Reference .

In particular, if you are comparing git checkout <non-branch> with git reset --hard <non-branch> (hotlinked):

_{(source: github.com )}

Note that in the case of git reset --hard master~3 you reserve a part of the DAG revisions - not a single branch refers to some commits. They are protected (by default) for 30 days using reflog ; they will eventually be trimmed (deleted).

Answer 3

git-reset hash sets the branch link to the given hash and, if necessary, checks it with --hard .

git-checkout hash sets the working tree to the specified hash; and if the hash is not the name of the branch, you will get a separate head.

ultimately, git deals with 3 things:

  working tree (your code) ------------------------------------------------------------------------- index/staging-area ------------------------------------------------------------------------- repository (bunch of commits, trees, branch names, etc) 

git-checkout by default simply updates the index and working tree and can optionally update something in the repository (with the -b option)

git-reset by default simply updates the repository and index, as well as possibly the working tree (with the --hard option)

You can think of a repository as follows:

  HEAD -> master refs: master -> sha_of_commit_X dev -> sha_of_commit_Y objects: (addressed by sha1) sha_of_commit_X, sha_of_commit_Y, sha_of_commit_Z, sha_of_commit_A .... 

git-reset handles what the branch reference points to.

Suppose your story looks like this:

  T--S--R--Q [master][dev] / A--B--C--D--E--F--G [topic1] \ Z--Y--X--W [topic2][topic3] 

Keep in mind that branches are simply names that are automatically committed when committed.

So, you have the following branches:

  master -> Q dev -> Q topic1 -> G topic2 -> W topic3 -> W 

And your current branch is topic2 , i.e. HEAD points to topic2.

 HEAD -> topic2 

Then git reset X will reset the topic2 name to point to X; this means that if you make a P commit in topic2, everything will look like this:

  T--S--R--Q [master][dev] / A--B--C--D--E--F--G [topic1] \ Z--Y--X--W [topic3] \ P [topic2]