Our practice is to only allow reviewed code to be commited to trunk. We use highly-focused, short-lived branches for all of our changes. We generally branch for each bug or technical task being worked on. Then, we create reviews for the commits on those branches. Once the code has been reviewed, the change is merged into trunk and the branch is removed.
The problem we have is that while we have excellent review coverage of our code, that isn't reflected when you use crucible's Review Coverage Overview report. It shows that we have 0% coverage. How do y'all do this? Are you comitting directly to trunk and then reviewing there? Or am I missing some key traceability feature that will carry the reviewed line status forward through a merge?
I also want to do code review on temporary branches that will later be removed. I fear however that the reviews lose the changesets and comments when the git server runs the garbage colletor and removes dangling commits, as there will be no branch pointing to them. Have you checked if this happened?
Everything below is tested on Ubuntu 17.10. I prefer to use Jira in a docker container because: 1. I can install Jira with a couple of commands. 2. I can start and stop Jira just by starting and s...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot