A quick skim over the landing page doesn't tell me why this is better than using Github Pull Requests
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.
Not sure what you mean by "codebrag is single-branch", as we do support multiple branches (from 2.0, maybe you tried the previous version?).
Also, SVN promoted a radically different model of working (huge commits, instead of multiple, fine-grained small commits).
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.
I've just added/fixed/clarified info about support for multiple git branches.
Regarding [wip], refactors and hotfixes - yeah, for larger refactors we create a separate branches, but this is more an exception than a rule.
It would be perfectly valid to use CB to review commits in the branch for which the PR is done, and then come back to it once more commits (with fixes) are added.
Also, using PR is only one style of work, and I don't think it's the "only right choice". Code reviews of code as it is written, that is during development of a feature, can help you to spot any problems faster. Waiting until a PR is done can result in a long feedback cycle.
You can use CB to track a specific branch that either your colleague is working on, or maybe you are working together.