On code commit history

by paragarora

Ever want to check quality of code, always start with quality of code commits. Code commits are generally last priority given by developers in the overall quality maintenance of code. A good code commit history quality is generally a good indicator of a good code quality as well.

As a general rule, don’t go with commit history quality of master branch, as those will be mainly ‘dev’ branch merges, ‘dev’ branch will be feature branch merge history. Feature branch generally are created with ticket id or shortcode of feature. Every feature will having rich commit history generally with ticket id.

Good commit message practices:
1: Written with imperative mood. Generally starts with ticket id followed with keywords as ‘fix’, ‘add’, ‘remove’ and not status update from developers with keywords as ‘fixed’, ‘added’ and ‘removed’. Good example is ‘DEV-21 fix infinite loop in login api’. A bad example is ‘fixed infinite loop in login api’ and a real bad example is ‘login loop in infinite loop will not happen now’
2: Not very short to provide no context, neither very long to create unreadable git commit history.
3: Commits are not ‘end of day’ commits with junk messages like ‘going to bed now’
4: Combining two tickets in the same fix e.g. ‘DEV-21 fix infinite loop in login api and DEV-32 fix logout api’ unless fix of both commits are same code. In which case should have a better format like ‘DEV-32 DEV-21 fix authentication retries check causing infinite loop in login and logout API’