While I'd like to think that this is _somewhat_ useful, I am a little hesitant. The issue I see with these bite-sized recipes is that there is no context, no place for nuance, and no hint that the behavior you see might be different for a variety of reasons.

Take the following for example:

> Oh shit, I need to change the message on my last commit!

> git commit --amend

It's important to realize here that if you are simply trying to edit the last commit message, you *should not* have anything in your index (that is, staged). Otherwise those changes will be recorded in the amended commit! What Git does is essentially move all the changes recorded in the commit you are amending _into_ the index, and then run `git commit -m <amended-message>` ... so if you have files in there, those will get mixed up with the ones in the commit.

Here's another one:

> Oh shit, I accidentally committed to the wrong branch!

> A lot of people have suggested using `cherry-pick` for this situation too, so take your pick on whatever one makes the most sense to you!

Umm ... No! The solution proposed (with `git reset --soft`) and a cherry-pick are NOT the same! Not even close! You will produce two completely different histories.

This final one, given when this page was written, _may be_ understandably incorrect

> Oh shit, I need to undo my changes to a file!

> `git checkout [saved hash] -- path/to/file`

There is the introduction of a new command called `git-restore` (https://git-scm.com/docs/git-restore) that (thankfully) is named more appropriately—it "restores" a file. I wrote a thread on it on Twitter, so if you are curious perhaps this will help: https://twitter.com/looselytyped/status/1501934009370042371

*Shameless plug for my book*

My book, Head First Git, was published by O'Reilly this January. I posted a submission here on HN about it https://news.ycombinator.com/item?id=30072348 so if you want any details feel free to peruse that.

Some links:

- Amazon: https://www.amazon.com/Head-First-Git-Learners-Understanding...

- O'Reilly's online platform (Needs subscription): https://learning.oreilly.com/library/view/head-first-git/978...

- Companion website: https://i-love-git.com/

(Edited for formatting)

*shameless plug*

> A possible way to make things interesting is to teach the material as a story with fiction characters and a bit of drama.

I am wrapping up the final touches on my latest book, Head First Git[1][2] and I will admit that it wasn't till I was midway through the book when it _really_ dawned on me on how important this is. Some of you might be familiar with the Head First series (if you are not, Head First Design Patterns [3] is a great place to start). It uses a very conversational tone, filled with characters, and lighthearted stories to explain technical issues. Lots of drama, visuals and exercises to help cement ideas.

I took on the project because I feel like I am intimately familiar with Git. Despite that, this book is one of the hardest things I've ever done, mostly because every chapter needs a narrative, with fictional characters, conversations, and problems they are aiming to solve, all while keeping a technical topic in scope.

I know that writing this book has certainly influenced how I might teach or speak on a topic in the future, but the OP is absolutely right—engaging the reader by making the stories about "people" certainly makes the book more interesting and easier to digest.

On the flip-side, it makes the book less _dense_.

[1] https://www.amazon.com/Head-First-Git-Learners-Understanding...

[2] https://learning.oreilly.com/library/view/head-first-git/978...

[3] https://www.amazon.com/Head-First-Design-Patterns-Object-Ori...

(edited for formatting)