|
|
|
|
|
by mplanchard
924 days ago
|
|
I was just wondering! I'm on Linux, so I wasn't sure on reading the web page whether it was something I'd be able to run, and the screenshots looked more desktop-app than web-app. We use GitLab at work, so I wouldn't be able to use it there, but I use GitHub and sourcehut for some personal and open source stuff. Code review is one of the few things I don't do in emacs, so there remains room for other tools :) |
|
The trick is to use git commits as the review comments. As in, you actually add // FIXME comments inline on someone else's branch. They then add another commit on top to remove them. Once you're done, you can either squash and merge or just merge. This is nice because it avoids "nit" comments. If you dislike a name someone picked, you just go change it directly yourself and avoid a round-trip, so it reduces exhaustion and grants a notion of ownership to the reviewer.
If you need discussion that isn't going to result in code changes (about design for instance) you do it on the relevant ticket. This also has the advantage that managers who stay away from code review tools still feel like they understand progress.
It helps to use a specific way of working with git to do this, and to have it integrated into your other tools. I use gitolite combined with YouTrack and TeamCity to implement this workflow, along with a kernel-like ownership tree, but it works well enough at least in a small team (I never got to try it in a big team).