I expect git checkout <commit> to flash both the working tree and index to the <commit> version. However, in some cases it will keep the current changes in both the working tree and index. For example:
git branch br1
git branch br2
git checkout br1
<make change M1 to file foo>
git add foo
<make change M2 to file foo>
git checkout br2
Now all the working tree/index changes made in branch br1 are kept in the branch br2, as git status on br2 won't give a clean message. I guess this is because the head of br1 and br2 originally have the same version of file foo, and Git can automatically detect this.
Question:
The git checkout command actually has two different (common) operating modes.
If you run git checkout <branch>, then you will switch to branch <branch>. All changes to the working tree will be kept -- and this works by merging the uncommitted changes to the target branch, so it can fail. Changes in the index will be stashed.
If you run git checkout <path>, then git will wipe out the changes to <path> in both the index and the working copy by getting them from the current commit.
So the purpose of git checkout <branch> is in case you decide that the changes you're making actually belong on a different branch.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With