[he_is_legend]

The trick(s) to git is not using `git add -A`, and being diligent (as in checking before you commit) about the changes that you are committing. Only add and commit what is relevant to the task that you are working on. But it's even simpler than that. Before you commit anything, check what you are about to commit. Is it what you expected? Is it relevant? Does it work? Has it been tested? Is it likely to pass a code review?

[chrismorgan]

> Before you commit anything, check what you are about to commit.

Better still, check it as you commit, by enabling the config option commit.verbose (e.g. `git config --global commit.verbose 1`), so that the full patch that is to be committed is shown in COMMIT_EDITMSG, not just the file names that you touched. This removes the race condition between review and commit.

(While on this topic, I also recommend commit.cleanup = scissors, and reading through `git config --help`, or at least skimming it for basic familiarity with what options are available to you. A few more that I like: merge.conflictStyle = diff3, diff.algorithm = histogram, mergetool.keepBackup = false.)

[jamil7]

Agree, I tend to go through my work with `git add --patch` and committing that way. I find it also works as a quick refresh on what you actually did and helps you decide how/if to split up your work into multiple commits.