My repository belongs to an organization I created. I want to prevent mistakes during pull requests. For example, accidentally allowing the master
branch to be merged from a branch other than development
.
How can I accomplish this?
My repository belongs to an organization I created. I want to prevent mistakes during pull requests. For example, accidentally allowing the master
branch to be merged from a branch other than development
.
How can I accomplish this?
I'm not aware of any direct mechanism in Git to do this. However there are alternative approaches.
This is a "hard process rules" vs. "delegation and training" problem that happens regularly in engineering and software development.
If you make master
a protected branch, then only those with elevated access to the protected branch can push to it, and/or merge in pull requests (ideally no one ever pushes directly without a pull request for review, unless fixing a merge/commit issue). There isn't really a need to make sure they only come from development
(in my opinion), that's just process that you need to agree on with everyone who is a lead/senior dev that is given those rights.
Git gives plenty of tools to revert things for the rare cases where someone messes up. Sure you'll likely end up with an extra commit or two, but that's not something disastrous. You lose so much more productivity by completely rigid, top-down process than by being a little looser and training people about best practices and making them better developers along the way through training and correction (when the odd error does occur).
At least that's my experience.
If you are not familiar with GitFlow - check it out here, but be aware an ideal CI/CD approach with good automated test coverage should not need a release branch and probably not develop either.
Here is an example of creating a github actions workflow that only allows merging from the staging branch or a hotfix/ branch.
name: Main Branch Protection
on:
pull_request:
branches:
- main
jobs:
check-branch:
runs-on: ubuntu-latest
steps:
- name: Check branch
run: |
if [[ ${GITHUB_HEAD_REF} != staging ]] && ! [[ ${GITHUB_HEAD_REF} =~ ^hotfix/ ]];
then
echo "Error: Pull request must come from 'staging' or 'hotfix/' branch"
exit 1
fi
Within the branch protection rules of the repository, you can enforce that this workflow succeeds before merging is allowed. (You should also have require pull request before merging selected too.)
I'm not aware of any direct mechanism in Git to do this. However there are alternative approaches.
This is a "hard process rules" vs. "delegation and training" problem that happens regularly in engineering and software development.
If you make master
a protected branch, then only those with elevated access to the protected branch can push to it, and/or merge in pull requests (ideally no one ever pushes directly without a pull request for review, unless fixing a merge/commit issue). There isn't really a need to make sure they only come from development
(in my opinion), that's just process that you need to agree on with everyone who is a lead/senior dev that is given those rights.
Git gives plenty of tools to revert things for the rare cases where someone messes up. Sure you'll likely end up with an extra commit or two, but that's not something disastrous. You lose so much more productivity by completely rigid, top-down process than by being a little looser and training people about best practices and making them better developers along the way through training and correction (when the odd error does occur).
At least that's my experience.
If you are not familiar with GitFlow - check it out here, but be aware an ideal CI/CD approach with good automated test coverage should not need a release branch and probably not develop either.
admin
. –
Penland My workaround for this is create a custom github workflows/action that only run when push to branch Y. Let's name this action "special_action"
Then setup branch protection on branch X, make sure that branch X only allow to merge a PR when "special_action" check is passed.
Since "special_action" is only run when there is a push/merge to Y branch, this setup may allow you to achieve what you want.
© 2022 - 2024 — McMap. All rights reserved.
admin
. – Penland