09 September 2016

Repo Reviews

It is very easy to get git repositories into horrible states. Summaries that are too long, having non-descriptive messages, or using the same message a number of commits in a row. Why then can we not fix untidy commits as part of code reviews? It happened at work recently and the main objection seemed to come from the fact that we had the branch pushed to remote (which you have to do to raise the merge request) and couldn't change the history because someone may have used it (in this case, the someone was probably Jenkins). I have a number of arguments against that. Firstly, if you have created a merge request, that implies that there is no more work to be done on that branch. If you change the history of the remote branch that invalidates someone else's work, the question should arise why was the merge request raised in the first place. Secondly, if you communicate that the remote history is going to change, anyone who might still be using it for whatever reason can sort it out themselves. Jenkins can be made to checkout a fresh copy of the repo each time. Yes it takes longer, but is a small price to pay for a clean log.

I use http://chris.beams.io/posts/git-commit/ as my guide to creating good commit messages. Obviously, you'll have your own practices, but why should you not be able to refuse merges if people have not followed them? You can use merge request tools to educate others in how to write good commit messages, they will learn to apply it, and we may end up with readable logs.

No comments:

Post a Comment