Branch protection newbie

I tried to study the doc but there are just too many options so let me just ask. I am the lead of a team of 4. Our setup (for better or worse) is a main branch which is “production”, a test branch for staging, then a branch named after each developer. The idea is that developers can work in their own named branch, can create new branches and so on. But they cannot themselves merge their named branch into main or test. I want to review the changes first via a pull request.

I know there are multiple ways to protect a branch but I am not sure which one is right for me. Can you help? Thanks!

The you’ll probably need to set up code owners settings too, on a per branch basis, to ensure that each developer has ownership over his/her own branch.

There have been quite some changes in the past year regarding which of these features are available to different types of GH accounts (e.g. Free users used to be able to use code ownership, but I believe it’s no longer so). Also, GH Teams introduces another layer of permissions which need to be considered.

To obtain this you need to enable branch protection rules that also apply to administrators (which IIRC also applies to collaborators). The trick is getting both branch protection rules and code ownership right, so they don’t clash with each other.

I’m unable to provide more details since the availability of these features has changed since I last experimented with them.

As long as only merging to main and test needs to be restricted (no further rules about users’ development branches) enabling branch protection for those two branches and requiring reviews before merge should be enough. :slightly_smiling_face:

Whether to apply the rules to admins, too, depends on whether you (assuming you are the repository admin) should be able to merge without reviews. :wink:

@airtower-luna , I’ve never quite understood what “repository admins” really includes. It seems to apply to repository owners and collaborators, so I guess it’s some sort of broad term in this context. Do you know the details of these term?

Not exactly, no. I know for the repositories I own it’s me. I haven’t worked with organizations and codeowners (IIRC the latter is for paid plans only), so I can’t say from experience how to configure it there. :slightly_smiling_face:

Luckily I was able to enjoy the few months in which code owners was available to free users, but I did stumble in some configurations nightmares in how these interacted with branch rules, and never quite managed to work out what “administrators” meant. I know it affected collaborators, but on Teams it seemed to have yet another meaning.

I really miss the code owners features. BTW, those repos where I had used code owners can still benefit from the feature, it’s just that I can no longer enable it on new repositories.

1 Like