Git from the Bottom Up – Reset, Stash, and Reflog

We wrap up Git from the Bottom Up by John Wiegley while Joe has a convenient excuse, Allen gets thrown under the bus, and Michael somehow made it worse.

The full show notes for this episode are available at https://www.codingblocks.net/episode195.

Sponsors

• Retool – Stop wrestling with UI libraries, hacking together data sources, and figuring out access controls, and instead start shipping apps that move your business forward.

News

• Thanks for the reviews on iTunes jessetsilva, Marco Fernandooo, and sysadmike702!
  • Want to help out the show? Leave us a review!

In Conclusion, …

Git Reset

• Git’s reset is likely one of the commands that people shy away from using because it can mess with your working tree as well as what commit HEAD references.
• reset is a reference editor, an index editor and a working tree editor.

git reset	Modifies HEAD?	Modifies the index?	Modifies the working tree?
--mixed	YES	YES. Removes all staged changes from the index, effectively unstaging them back to the working tree.	YES. All changes from the reset commit(s) are put in the working tree. Any previous changes are merged with the reset commit(s)’s changes in the working tree.
--soft	YES	YES. All changes from the reset commit(s) are put in the index. Any previously staged changes are merged with the reset commit(s)’s changes in the index.	NO. Any changes in the working tree are left untouched.
--hard	YES	YES. Clears the index of any staged changes.	YES. Clears the working tree of any unstaged changes.

What do the git reset mode flags change?

Mixed reset

• --mixed is the default mode.
• If you do a reset --mixed of more than one commit, all of those changes will be put back in the working tree together essentially setting you up for a squash of those commits.

Soft Reset

• These two commands are equivalent, both effectively ignoring the last commit:
  • git reset --soft HEAD^
  • git update-ref HEAD HEAD^
• If you did a git status after either of the previous commands, you’d see more changes because your working tree is now being compared to a different commit, assuming you previously had changes in your working tree.
  • This effectively allows you to create a new commit in place of the old one.
    • Instead of doing this, you can always do git commit --amend.
• Similar to the use of --mixed for multiple commits, if you do a reset --soft of more than one commit, all of those changes will be put back in the index together essentially setting you up for a squash of those commits.

Hard Reset

• This can be one of the most consequential commands.
• Performing git reset --hard HEAD will get rid of any changes in your index and working tree to all tracked files, such that all of your files will match the contents of HEAD.
• If you do a