| Completely agree with parent and grand-parent. For me, a nice clean commit history is an investment in future maintenance. Following the rules described above means that you get a lot of context on why code was changed: * the invidivual commit which should contain a description of the change if the change is not self explanatory or not 'intuitive', the individual commit should consist of only 1 functional change * the commits surrounding it, the feature branch (clearly visible because of the merge commits) * the issue number on the commit itself and possibly in the merge commit I've found all this context very informative for projects that are in maintenance mode and still need changes from time to time. Obviously, the higher the quality of the commit history, the higher the quality of the information you get out of it. Meaning: if you put a rename with an impact over the whole code base (because the original name just happened to bother you that day) together with a bugfix in the same commit and the commit message has the very informative text 'fix', and the referenced issue mentions 'add support for blah' (but the commit obviously does not implement anything related to 'blah'), then... well, yeah, then how you organise your commit history does not really matter. |
Absolutely this too!
My process is to create a feature branch named "ISSUE-123-issue-description"
The benefit of this is all changes are tracked (and tested) against a specific issue in bug management software.
It also prevents people making small / unrelated changes or fixes in association with another task. If these are grouped in together in a single and unrelated task they won't be trackable or testable.