How to prevent pushing new branch whose name match exising protection rule

We have branch protection rule ‘stable-v*’ to protect existing branches like stable-v1.0 and stable-v2.0, to prevent our team member from pushing into these branch directly. However, this rule can not restrict new branch matching the same pattern to be pushed accidently. Once pushed, the new branch will be protected and not be easy to remove. 

As the adminitrator, I have to disable the rule first, delete the branch, then re-enabled the rule.

Is there any method to prevent our team member to push such branch? 


Hi @dummyhuan,

Thank you for being here! I can’t think of any obvious way to significantly improve your method. We’re always working to improve GitHub, and we consider every suggestion we receive. I’ve logged this as a feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.



Hi @andreagriffiths11,

I consider it a pretty bad UX to have branch protection rules restricting who can push only apply after a branch has been pushed for the first time. The hook that GitHub uses should ideally check the name of the branch being created for existing protection rules and apply them as if it was an existing branch to which someone was trying to push.

I have tried using a * pattern to prevent pushing new branches to our repo (we only accept PRs from forks) to discover that this was just not working as expected.


I agree with @zimmi48 , this seems more like a bug in the “branch protection” feature at the moment, unless I’m missing something about the rational for the current behavior. @andreagriffiths11  do you have more information on this?


A year has passed and still no feedback.

It certainly seems a bug to me (it seems that’s the answer to my own question too: see Branch protection not working as I expected).

1 Like

Any idea if this bug will be fixed any time soon? Branch protection should apply to incoming new branches too.

Any idea if this bug will be fixed any time soon?

I opened a case to GitHub. They confirmed this to be a “known behaviour” and that it was internally queued to be reviewed and (possibly) corrected.

No time frame was given to me, though.

1 Like

Aahhh, I see. Thank you. Do you have the link to the case?

Do you have the link to the case?

No, for what I’ve seen, they are not publicly shareable. Anyway, I think I can copy & paste the exact answer from GitHub support:

We have an open feature request for extending branch protections to branch creation, and I’ve added [redacted] as an interested party. If this change is made, it will be posted on our GitHub Changelog, so I’d suggest you follow that for related updates.

In the same boat. We have devs who forget or mistype our branch naming convention, ending up with a wrongly named branch they then can’t delete :frowning:

1 Like

This still has no traction?! Its a pretty serious bug that kinda makes “branch protection” moot, in that while devs can’t push to an existing branch thats protected, they can easily just create a new branch of the same pattern to get around the “protection”. We (and likely many other teams) have specific branch names/patterns for workflows. We protect the ones that will either break the job they target (ie: - in branch names targeting Puppet environments) or trigger build pipelines for deployments. Allowing a new branch to be pushed that matches the “protection” pattern will trigger these situations and create a cleanup headache. We have had to implement other more complicated protection methods and automated cleanup tasks because of this hole.


This still has no traction?!

I had no new notices, no, and I didn’t see anything related on the Changelog.


I like how you have a feature to give users the ability to be referenced by an arbitrary custom pronoun but you don’t have a feature to prevent arbitrary pushes to a repo from organization members. For reference, branch protection works in Gitlab.


This feature would be extremely useful. My project has a lot of active developers and we run into this issue a few times a month. We are finding that basic GitHub does not have any of the features needed for highly active projects.

1 Like

+1. This is badly needed.