git commit best practices

Question

I am using git to manage a C++ project. When I am working on the projects, I find it hard to organize the changes into commits when changing things that are related to many plac

Answer 1

What I am asking is the PHILOSOPHY part.

I think I can answer this because I have been involved in some personal research recently.

One should focus in creating an atomic commit. Which means that it's necessary to take some extra care in a few things for a commit:

• It shouldn't have any value if done partly
• It shouldn't break the build
• It should contain a good message and body for traceability (with tickets reference whenever possible)
• It shouldn't contain a lot of diff noise (whitespace and style changes, unless the commit is specific for that)

Commits should be focused in one change, and one change only. Anything more than that can have bad side-effects.

Some people might argue that this is too much, that it is not practical. But the best argument in favor of it, even for small companies, is the fact that bulding atomic commits will force your design to be more decoupled and consistent, because one requirement to achieve full optimal atomic commits is to have a healthy codebase that is not a mess.

If you force good commit practices consistently, you will be able to drive the engineering culture and the code itself to a better state.