Its been a few weeks but there are still two topics left to cover from
the original AMA session. This week's topic is Branches. As always,
below are some links to the original documents and chat logs from the
IRC session, and the main body of this mail is the questions and
answers pulled directly from the Q&A sheet that specifically relate to
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
* AMA Blog post
* Here is this email in hackmd if you wish to view it there:
## Topic: Branches
Force pushing - Protected Branches
- Question: Fedora forbids force-push in the main projects but allows
them in forks. Would this be feasible in GitLab in a way that people
- Answer: This can be done with Protected branches, basically
Archived branches - Protected Branches
- Question: Fedora supports the concept of retired git `branch` (ie:
archived) that no-one can commit. Does GitLab have an equivalent
concept? (The retired status is not something project admins can
- Answer: Yes this is possible with Protected Branches
- Question: Extending to above question, the sla's or eol dates are
coming from a 3rd party service, when a user pushes to git branch, it
will check the eol in that service and rejects it if it is already
eol'd. Is this possible in GitLab?
- Answer: Instead of this we would probably use the Protected
Branches in GitLab. We could leverage the APIs to mass configure the
branches on eol dates. That would mean that for each git push we don’t
need to look at a 3rd party service to know if we can push or not.
- Question: It is not allowed for users to delete the branches, only
certain people with certain access levels are allowed to perform this
operation. Is this possible in GitLab?
- Answer: Yes protected branches can be used here
- Question: In CentOS, members of a group (say: storage-sig) can push
to any branch starting with c<int>-<sig-name>-* (so for example, they
can push to : c8-storage-sig-v2.0 or c7-storage-sig), but they cannot
push to any other branches, like: c8, c7 or any of the branches
starting with c8-kernel-sig and so on. Would this be doable in GitLab?
(in a way that project owner/maintainer cannot edit?)
- Answer: A Custom Push Rule and server hook (pre-recieve Git
hooks behind the scenes) could help with this.
- Question: Can we set permissions at branch level? Esp can we set
them with some regex matching?
- Answer: permissions accept wildcards, but not regexes. Regex can
be used with custom push rules. See
- Question: Is it possible to hide these retired branches from the UI?
Say, hide branch names with f30 or lower?
- Answer: This is not possible currently
- Question: Currently a user is not allowed to rewrite the history. Is
it possible? It would be nice to allow only certain people to do so.
Although we might not use this, but its good to have just in case if
we ever need it.
- Answer: by default, only the `master` branch is protected
against force push and deletion. It’s possible to configure other
branches to be protected and who has permission to override.
Branch level orphaning
- Question: Orphaning a package or repo? A maintainer (owner) of the
package can decide to orphan a package, the maintainer should only be
able to assign the package to the `orphan` user or any of the other
maintainers of the package only. Is this possible to set this branch
level as well?
- Answer: Yes, in the sense that who is allowed to push or merge
to a specific branch is controllable at the user or group level. This
can be at the specific branch level or based on a wildcard match based
on branch name. See configuring protected branches for more details.
There is one more topic from the AMA session on Naming issues with `+`
and I will include any other Q&A's from the sheet that have not been
posted yet. This will be out next week.
I hope you have been finding this concentrated topic email useful and
informative. This has been an extremely different year for everyone &
we as a team have found ourselves with very little time to give to
this project since the initial announcement, but I hope to engage with
the community much more directly in 2021 as I work through this GitLab
project formally to make sure we are making the best choices for
everyone, straight through from end user to sys-admin, and everyone in
Have a lovely weekend everyone and thank you again for your engagement
Community Platform Engineering Team
Red Hat EMEA