A bunch of insights I've learnt in my time as a lead developer about commit policies and code reviews.

1. HOW WE GIT
Commits and Code Review

2. COMMIT EARLY,
COMMIT OFTEN

3. CECO
Commit on every milestone, regardless of major or minor
When using issue trackers, commit before closing your case
Ensure that the latest commit is production ready

4. BE A STORY TELLER

5. Be A Story Teller
Git commit comments should tell a story
We read commit comments to find out what happened
The less verbose your comments are, the more annoying others
will be
Conclusion - write verbose comments to stop others from
disturbing you
New acronym: RTFC (Read The F**king Comments)

6. How NOT to commit
You: Fixes header
Team: Why does the header
needs fixing?
You: Fixes header again
Team: WTF? Again?

7. How to commit
You: Fixes header bug where the
dropdowns don’t work, caused by
a change of css ID. Somebody needs
to be shot.
Team: It wasn’t me.
You: Accidentally forgot to include
the new LESS file (foo.less).
Team: And I was just about to file
a bug to make you look bad...

8. Refer to cases
You: Closes #45675 -
Changed header styling to use JS-based
dropdowns instead of plain CSS.
Team: Now I can check PT and find
out why my code was removed and
replaced with JS instead.

9. Benefits
CECO makes it possible to progressively rewind the commit
pointer to see which commit introduced the bug
Small commits allow for easier code review
Small commits make it easier to course correct during code
review
Verbose comments reduce the need to talk face-to-face (very
handy when it dealing with those working from home/remote)

10. Code Review Policies

11. Code Review Policies
Code review is not optional - it is a must for every tech lead
Code review should lead to refactors, not rejection
Make a distinction between convention and logic
Convention = Enforce it. Logic = Refactor it.

12. Code Review Policies
When reviewing code, take a high level perspective
Aim to reduce code (leaner codebase)
Aim to modularize reusable components

13. Code Review Pointers
Good code tend to reinforce current codebase
YAGNI is a good driving principle, but beware of bulimic code
too
Lean code = good base to continue adding features
Bulimic code = code that’s simple because it’s useless

14. Resolving Code Reviews
Code reviews should be part of the team nurturing process
Employee performance should NOT be affected by code reviews
Aim to improve, not to blame or humiliate
Codebase quality determines the morale of your team

15. ~ the end ~