Solve one problem at a time

When using git log to look through the history of codebases, I often see large commits that combine several changes.

These also lead to vague commit messages like "Changes", "wip" or "Fixes".

These aren't helpful when reviewing the history and large commits are difficult to review and revert if there is a problem.

Each commit should be focused on a single change, whether its adding part of a new feature, fixing a bug or refactoring.

If it's a combination, they should be split into separate commits.

Each commit should have its own well-written commit message that explains why the change was needed, any consequences or manual deployment steps, alternative approaches that were tried, issues encountered and any follow up actions.

If you can't properly describe the changes made in a commit, the commit is too big.

You should uncommit the changes and use git add -p to create a more focused commit.

This is why I don't squash commits.

If people have made an effort to create good commits with good commit messages, I don't want them to be lost when the commits are merged.

I want to keep the history of the changes intact and as it originally was.

I do sometimes need to tidy up my own commits, though, before I push them for anyone else to see.