Have you ever considered git as a collaboration tool to discuss code issues or alternative solutions? Me neither. My colleague,Viktor, has conducted a code review recently and used git for supporting it. He quickly won me for this idea and let me share it.

We do quite a lot of code reviews at TechTalk as a part of the agile development process we use. We do this in two stages. On the first stage, the development team itself takes care of the code quality. This is either done with pair programming or with team review meetings. On the second stage (ideally bi-monthly or so), we ask someone outside of the team to spend some time with the code and discuss the findings. This someone is usually an experienced developer from another team.

I have also conducted such “external” code reviews. I like to do it low-tech and very informal, so I collect my findings as simple notes. (I use OneNote for this, but a notepad would be just as fine.) I categorize these notes into general and concrete issues. In the code review meeting, I go through these notes and discuss it with the team. The majority of these notes are related to a small piece of code in the application. For the concrete issues, I even give suggested solutions usually. These are all in the notes I have prepared.

It works fine, but finding these code parts during the meeting is pretty annoying sometimes. For trivial issues where everyone is fine with the proposed fix, the process of handing over the notes to someone who will later update the code feels cumbersome.

The idea of Viktor was to use git, more precisely git branches for these code-related comments, especially where there is a suggested alternative. Since creating switching branches is super easy in git, this sounds like a good tool to try.

Actually the idea is not totally new. For example, the code review feature of TFS also uses the source control features to control the process (but does not work with git unfortunately). Also the github pull requests can be used like that. Still, using pure git has the big advantage of being simple and geeky.

These are our consolidated rules now:

1. Create a new branch for every topic. I recommend using some naming convention (e.g. “review-inputmodel”)
2. Create a commit for every note you want to make. You can use the commit comments for describing the problem more in detail.
3. Make sure that these comment-commits are isolated and cherry-pickable.
4. For questions or problems without a suggested solution, you can have commits that add (TODO)comments to the code.
5. For these kind of smaller comments, you can create a single branch, like “review-commits”, because these will never be merged back anyway.
6. In the meeting, you can go through the branches/commits. You can show the commit diff and also checkout the branch to show how the code behaves.
7. The review-branches can be pushed up. If you don’t want to “pollute” your main repository with review branches, you can use an alternative remote for this (stored in a file share, for example).
8. The team can review the commits later once more and either use them as a starting point for a proper fix.
9. Once, the necessary review result actions have been taken, the branches can be deleted.

Happy gitting and reviewing! (Thanks to Viktor Nemes for the inputs.)