BitBucket commit review traceability

[MarcinGil]

Hi!

I'm working on a project that has specific traceability requirements, notably any commit that hits `master` or any of long running branches needs to be traceable back to its review (pull-request).

Ie. imagine a feature branch with 15 commits, it gets its pull request and then gets merged. While browsing `master` history I pick up randomly one of these commits and I need to be able to navigate to the pull request/review (evidence of review).

Moreover, let's say I have cherry-picked 2 commits off to a long running version branch (eg. some small fixes). These two commits need to be again traceable back to the original review. It's an option that such commits will get another branch and pull request but that's an overkill since they were already reviewed, right?

Is it doable in BitBucket?

Thanks,
-Marcin

[Aron Gombas _Midori_]

The first problem is that you assume that there is a 1:1 relation between commits and pull requests, which is not true. 

Say, you create X on the feature branch F, then it gets merged to release branch R, and then to master. Which pull request do you expect to see, the one from F to R or the one from R to master?

Probably all... Or the very first one, as I guess a review from F to R will make further code reviews less important or unnecessary.

I'd rather focus on making the commit traceable to its original feature branch and to the pull request that merged it from the feature branch to release branch. You could link the commit and the feature branch by using the originating Jira issue's (story type, bug type, etc.) key in it.

You could use the Commit Policy app for that.

Disclaimer: I'm a developer of this app.

[MarcinGil]

Hmm.. never thought of having two pull requests - per branch. We usually do reviews while merging to just one branch, then cherry picking.
And yes, our current system has 1:1 commit to review ratio - with link to review stored within commit message (pre-commit or pre-push review). That's its biggest disadvantage: no context of change. And that's what we try to overcome.

However A-Spice requirements are that you must always have an evidence of review for each line of code on production branches -> commit traceable to it's review regardless whether it has been merged/rebased/cherry-picked.

One solution is to have short lived integration branches, with cherry-picks, that has separate pull request. Or, as you suggested, many pull requests for the same feature branch.

Good food for thought, thanks!