Unwanted further approval

[giulix]

Hi all, new user here so please be gentle...

I work for a company where basically everyone who adds a new feature becomes the owner of that feature and we use Atlassian (Confluence, Jira, Bitbucket, etc). So, this is how we work:

1) I create a new branch for my feature
2) I work locally on the branch
3) When the work is done, I commit and push "my" branch
4) I create a Pull Request
5) Some teammate reviews my code and, if he's happy with it, he approves the PR
6) I merge the changes into a public branch (a branch that is used by all to integrate their new features), the branch is automatically built and -if the build is successful- it is automatically deployed onto a test server.

Now, say I find a bug in my code during testing. I fix it, and I have to go through the entire process again (2-6).

I would like that, since I am now the owner of the new feature, I weren't required to go through the entire approval process again, but only do 2, 3 and 6.

Is this possible?

Thank you,

g.

[Daniil Penkin]

Hello @giulix,

This is more a questions of the desired workflow in your company as well as other things around your setup.

First of all, if you have no branch permissions enforced, it is rather a matter of conventions that you have in your company. What I mean is if there're no constraints around branch merges or pull request approvals set up in the repository, Bitbucket won't prevent you from merging a branch without creating a pull request and/or from merging a pull request without approvals or even reviewers, but obviously this is only the technical side of things. Your colleagues on the other hand might not be happy with you making some changes no one has reviewed, even though they're in another part of the product you are building together.

If you do have branch permissions in place, they work with no regard to the actual files you're pushing but rather branches you're updating. That is, Bitbucket doesn't know about features of your product, and all files in your repository are just text or binary files. However, you can make use of conventions here too. For instance, you can create a branch pattern rule with some specific prefix and configure merge rules you want for that type of branches. When working on some code later on, you can apply one of those rules by naming your branch accordingly.

Lastly, if your code is split across multiple repositories, there might be different rules for each of them. For instance, one might not need any pull requests at all while the other one can require at least two approvals on any change.

Does this make sense? Let me know if you have any questions.

Cheers,
Daniil

[giulix]

Hello Daniil and thank you very much for your elucidation.

I think we definitely have branch permissions in place, as it is impossible for me to merge my changes into any "public" branch without the prior approval of my colleagues.
In your post you mention branch pattern rules; would it be possible to implement a merging rule that says:
1) Require approval before merging a new "private" branch into a "public" branch
2) Once approval has been obtained, and the new "private" branch has been merged into the "public" branch,
3) Allow following merges of the same "private" branch into the same "public" branch without requiring further pull requests and approvals?

It that is possible, I think it wouldn't be much of an adjustment for my organization, as we already have naming conventions in place that differentiate between development ("private") and production ("public") branches, as the article you linked recommends.

Thank you,

g.

[Daniil Penkin]

Hello @giulix,

The branch permissions are stateless in terms of how they are applied to the push attempts (this includes merge attempts). So unfortunately no, it is not possible to differentiate first and later on changes of the same branch. But if you come up with a convention to name a later on update with a different pattern, you can simulate the behaviour you described. Obviously, you can abuse such setup, but this is what conventions are for.

Hope this helps.

Cheers,
Daniil