The new 1.19 branch-protection with wildcards is a great long awaited feature. Thanks @lunny
I want to protect ‘master’ and “*-fix” branches - this works.
We need 4 eyes principle in that branches, so i want to only allow changes by merge-requests. But how can team members itself create new branches? This works only with push-permission, but then the 4AP is broken.
Would make sense to allow whitelisted mergers to allow to create a branch.
What do you think?
Has someone a workaround (except API)
In my use case, I have master set up with Disable push, Enable Merge Whitelist, and Required approvals set to 2. Branches like feature/xxx and fix/xxx can be pushed to by anyone. Once features/fixes are ready, developers create a pull request to merge into master which is then reviewed before being merged by someone on the merge whitelist.
In this case, only master is protected and all releases are created from it. If you have multiple versions of software, you could have multiple protected masters like master is latest (say v3), master/v1 is old v1, master/v2 is old v2, etc.
For new features sure we merge into protected master.
We’re releasing every two weeks (every print) a new major release, which gets an own branch called “fix-branch”, so we have several versions.
(Most) Fixes are merged into master and then picked down into the fix-branches (released versions). So we also need to protect them the same way as the master.
But: then no dev-member can create a new “fix-branch”
Hey @folke did you ever find a solution for this? I am facing the exact same problem. We implemented protection of the main/master and all release banches but had to quickly reverse that change because it turned out branch creation was no longer possible.
I’ve setup i trigger in our CI/CD tool “Teamcity” which created the (protected) fix-branches after pushing a tag to the repo (and after a successful build).
Same could be implemented with server side hooks at gitea