I kinda see the gamification point. That's pretty ... okay, I suppose. I do like how you can 'like' a given line. Might be even better if you could like a block/set of lines/function/etc. That little heart to the left is about the only thing I see about it that sets it apart from traditional pull-request-as-code-review.
Unfortunately, codebrag is single-branch only, and triggers reviews on commit. That's a little ... weird. That's how a team I was on did code reviews about seven years ago. But we were also using SVN at the time.
SOP these days is issue a pull request, the PR gets reviewed and when it passes muster is merged. I don't know anyone who does per-commit code reviews.
I guess you could set it up to track commits on your stable branch, and when merge commits come through from topic branches you can review then. But that seems a bit backward.
From the comment replies it sounded like it can only be on a single branch at a time unless you want to restart the app every time you switched branches. Does each developer run their own instance?
I'd assumed all of that post and the comments were about version 2.0, considering it was linked to from the 2.0 documentation "getting started," you can understand my confusion.
The FAQ only says it supports branches (not a word about multiple branches, unlike previous blog articles that took me a while to dig out) -- it makes it seem like 'sure, you can set up code reviews on a branch!'
The link to the blog from the docs page points to nowhere. I just found it by going back to the beginning.
I was also trying to find version deltas (e.g., what's new about version 2.0 from 1.x?), and I guess some 20 second youtube videos count but... if the code reviews are there, shouldn't there be documentation, too?
I haven't used the product; it looks kind of interesting... if extraordinarily light on the details. It gives me no incentive whatsoever to try it out - the only differentiating factor it has between the github pull request review cycle is the per-commit review (I still can't quite git over this) and the ability to heart a line.
If you have [wip] tags for larger e.g., refactors, how do you keep your single branch in a releasable state for production hotfixes? Does every commit kick off a regression test in jenkins? If a [wip] breaks your tests but leaves it in a releasable state, how do you know? If you did know and you needed to get a hotfix out ASAP for something else, do you revert the commit, or do you rebase to a known-stable tag? That just seems ... dangerous.
It doesn't seem like the most workable flow for a continuously live project. It might work fine for products that you can release a stable version of every couple of months.
"Because every commit gets reviewed" doesn't quite cut it for large codebases, even with small teams. Code reviews don't catch everything.
Word. You're welcome - it looks like an interesting idea for a tool, I just don't have a use for it at the moment :) I'll keep an eye on it. My curiosity is definitely there, if the gamification bit gets fleshed out more (and if you weren't so adamant about no PR reviews ;) ).
Unfortunately, codebrag is single-branch only, and triggers reviews on commit. That's a little ... weird. That's how a team I was on did code reviews about seven years ago. But we were also using SVN at the time.
SOP these days is issue a pull request, the PR gets reviewed and when it passes muster is merged. I don't know anyone who does per-commit code reviews.
I guess you could set it up to track commits on your stable branch, and when merge commits come through from topic branches you can review then. But that seems a bit backward.