git stash save saves the current index and working directory state as an independent commits accessible through the ref refs/stash. The git stash pop command restores the context saved by a previous save operation on top of your current working directory and index. The pop operation takes the stash content and merges those changes into the current state. These two basic commands implement a stack of stash states.

The two basic stash commands, git stash save and git stash pop, implement a stack of stash states. If a conflict resolution is needed when doing a git stash pop, Git will not automatically drop the state so you should also do a git stash drop.

git stash also provides a quick way to get around the problem where a git pull is not possible due to it overwriting your local changes. You can get around this problem by doing the git pull in between git stash save and git stash pop.

There is also git stash branch which can be used when stashed work cannot apply cleanly to the current branch.

Git's reflog has you covered when you are confused at what just happened or have just done an operation that you shouldn't have done. Using the reflog, you can see that operations happened as you expected on the branches that you intended, and can also recover lost commits in case something went astray.

The reflog allows you to see the operations that happened and recover lost commits. It is a record of changes to the tips of branches within nonbare repositories. Every time an update is made to any ref, including HEAD, the reflog is updated to record how that ref has changed. It can be thought of as a trail of bread crumbs showing where you and your refs have been. Any Git operation that modifies a ref or changes the tip of a branch is recorded.

git reflog show displays the transactions for only one ref at a time. The default ref is HEAD. Since branch names are also refs, the git reflog command can be passed a branch name to display its changes.

Each line of the reflog shows an individual transaction from the history of the ref.

The interesting aspect of the reflog is that each of the sequentially numbered names like HEAD@{1} can be used as symbolic names for any Git command that takes a commit.

The reflog doesn't become huge because Git runs a garbage collection process occasionally. During this, some of the older reflog entries are expired and dropped.