Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Unwanted further approval


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,



Daniil Penkin
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jan 05, 2020

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.


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,


Daniil Penkin
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jan 12, 2020

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.



Log in or Sign up to comment
AUG Leaders

Atlassian Community Events