If you commit in the wrong order and want to set it straight, learn to use "git rebase -i" (i.e. --interactive)

"git reset --patch" is useful for unraveling changes that were wrongly combined into a single commit.

I do already do! :) I use interactive rebase to squash multiple commits together when I need it.

However, I just find it easier to start from scratch if I changed 4 files at once, wanted the changes spread out over 3 commits, and I did those in the wrong order or something.

Interactive rebasing works fine for teasing apart commits as well (maybe slightly clumsier, but c'mon... it's git, it's _supposed_ to be a frustrating UX)

Yes... it is, until you realize it's a command line manipulation of a data structure.

Rebase, branching, diff, cherry pick, merging is just manipulating a DAG.

When you're on your own branch it's often easier to think of it as a linked list.

Even if you're on your own branch you can easily get a DAG after rebasing or resetting. The reflog keeps track of the history of all refs (ie. branch names) that you change. After you rebase your old commits are still there! It's actually quite hard to remove commits.

Trusting the reflog is key to becoming good at git.

How do you do that?

I use interactive rebasing as the backdrop for teasing apart commits that are not the HEAD commit; it provides the navigation through the commits.

The cherry-pick operations that underpin rebase are not what actually does the teasing-apart, though; I do that with with git reset --interactive HEAD^ when I've landed using "edit" on the commit I want to separate.