Self-review

Whether you have someone else reviewing your code or not, with Intentional Commits you are your own first code reviewer before each commit. It's efficient, since it provides early feedback for many mistakes or potential improvements shortly after making the change; it prevents wasting the code reviewer's time with things you could have found yourself; and it is easier to review changes if they are small and well scoped. The smaller and the better scoped your changes, the quicker the self-review. When Intentional Commits is applied well and with good habits overall, the self-review of small, well-scoped changes becomes a quick sanity-check and often takes just a few seconds.

During the self-review, you might sometimes catch cases where you didn't apply scope discipline as well as you would wish you did. Especially when you are just starting to be more intentional with your version control habits, this can happen more frequently. In some of these cases, you might be able to stash some of the changes for later or stage only a subset of the changes for the commit. In other cases you might want to accept it and treat it as feedback for continuous improvement. These habits will likely not be formed overnight.

How to do a self-review with Git

There are many ways a self-review can be done. In IDEs or graphical GUI clients, one can usually show the diff for each file before committing. When using Git in the terminal, one quick way is to do git diff (or git diff --staged if the files are already staged). The workflow can roughly look like this: git status for an overview of the changed files, then git diff for the actual self-review, followed by git add .. Another option is to use patch staging, git add -p. Git then displays the diff of each hunk individually, one after another. This can help to self-review the changes in smaller parts, but if the context of the whole changeset is important, git diff can be more appropriate.