Make your commits better with git <command> -p
Yesterday, I finished up the initial code for my third feature at work (Yes, I can still count them on one hand). It came time to submit my code for review, and I realized I had done this to myself:
[Image description: A screenshot of the shell output of running the command 'git status.' It shows dark pink text on a black background, showing 38 modified, deleted, or new uncommitted files.]
This is why you commit early and often, folks. So it's not 4:30 on a Friday afternoon, you're the last one in the office, and you're late picking up your wife because you've been trying to make Perfect Commits (TM), which means you didn't commit anything at all for days at a time until it was done. Hypothetically. Not that that happened.
What I should have done is commit things along the way in logical chunks. But sometimes, when you're a noob and you're not entirely sure where you're going until you get there, it's hard to know what a 'logical' chunk looks like.
If you also want to commit more often, but not have messy, half-done features committed over and over, there are two git tools that can make your life easier.
Strategy 1: Commit broken things however much you want. Use `git rebase --interactive` to rewrite your history once the path is a little more clear.
Caveat: You should only use this strategy when your code is isolated while you're working on it, i.e., you're the only one working on your topic branch. Otherwise, when you rewrite history, you risk completely borking other people's histories if they're based on the one you just rewrote out from under them.
Strategy 2: Commit often, but use the `--patch` or `-p` flag to interactively choose chunks of code (rather than full files) to add, stash, or checkout. This strategy is great, especially when you can't rewrite history.
dededos
theartofmadeline
snowghoul
ellievsbear
tangentwithtanner
titsay
origamiaround