I'm looking for an advice reflecting my point of view. First, I will explain my point of view.

My point of view

I'm working in a big company as a C++ developer, we are using GIT. I'm going to make a talk on how our developers should organize GIT commits. The main idea is that most of commits should be pure refactoring with no functional changes.

The workflow of implementing a feature A should look as follows:

Find out whether A fits to current architecture If not, refactor current architecture so that feature A now fits into it Implement A smoothly, with as little additional changes as possible

The workflow of fixing a bug B should look as follows:

Find out the root cause of B and whether it is obvious and easy to fix If not, refactor current code so that B is obvious and easy to fix Fix B smoothly, with as little additional changes as possible

In both cases there are as little functional changes to the code as possible. I assume that refactoring changes are better than function changes since they are less bug-prone (some may be automated), easier to test (nothing should change at all) and thus are easier to review (requires less attention from a reviewer).

The ideal situation is when you do several refactoring commits with possibly many lines of code changed, and then a one-line commit which actually fixes the bug. Since bug fixes require high attention from reviewers, the shorter they are, the better.

To enforce this idea I recommend to strictly categorize each commit into one of the following types, explicitly marking each commit message with a little symbol:

(~) Marks pure refactoring

(-) Marks bug fix

(+) Marks new feature implemented

(*) Marks changes in existing features, which are not due to bug fixes

(=) Marks some trivial changes (comments, formatting, rename files and variables, etc.)

The recommendation is to favor (=) and (~), and make sure (-) and (*) are as small as possible. As for (+), well... sometimes we just need to write some code :)

The question

I would like to hear some others experts opinion about this approach - is this sensible? Are there pitfalls? Has someone experience with a similar model? So far I found this related: Commit Often, Perfect Later, Publish Once: Git Best Practices, but not completely relevant. I don't remember such recommendations in Macconel's Code Complete, and IIRC it does not recommend how to organize code changes.

Note that the topic is not specific to GIT, but since GIT has excellent tools for local history management and commit crafting, the topic is tightly bound to GIT.