Restrict branch X to be merged only from one specific branch Y in Github
Asked Answered
P

3

18

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?

Paederast answered 29/9, 2017 at 19:38 Comment(0)
S
1

No direct solution

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.

Alternative Approach

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.

Note about GitFLow

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.

Saprolite answered 29/9, 2017 at 21:36 Comment(7)
While this answer is partially true, allowing merges from specific branch makes it easier for quality control. e.g. if your org follow git-flow, then this can be easily practiced by only allowing merges from certain branches to protected branches. This reduces cognitive load for the PR reviewer by automating these small details. For exceptional situations you can always request override from the admin.Penland
@Penland I don't dispute that - this is providing an alternative perspective and therefore an alternate solution. Whether this approach or another is better will depend on a lot of factors. It sounds like you have a working system to automate this - perhaps provide an alternate answer?Saprolite
@Saprolite I was looking for the same, seems there is no way to enforce this ruleCarey
@Carey No direct way in git that I'm aware of. With Github or Gitlab, both provide branch protection and if you are using merge requests for merges, then you can require approvals and one checklist item would be making sure you are merging from the right places to the right places. My team uses a branch strategy inspired by Gitflow, and have both a develop and master branch, but we allow merges to master from primarily develop, but sometimes directly from a hotfix branch... But both develop and master require a merge request/pull request and approvalsSaprolite
Added intro section to clarify this isn't a direct answer due to all the haters (lol). While I understand this doesn't directly answer the question, it does not appear there is a direct way to do this. Some people coming here are not aware of the alternatives, which I've seen work in practice (and actively use in a large engineering organization). 6 years up and no other answer - I'm a little confused by the recent downvotes...Saprolite
The question is about pull request. Pull requests are not a Git feature. So saying there is no Git solution is meaningless. Of course there is no Git solution. But there might be a GitHub solution.Richert
@Richert Feel free to post any alternate solution as an answer. This answer does suggest Gitlab/Github features as part of the alternate solution (not purely git related answer)Saprolite
C
2

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.) enter image description here

Centra answered 18/7 at 18:8 Comment(0)
S
1

No direct solution

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.

Alternative Approach

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.

Note about GitFLow

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.

Saprolite answered 29/9, 2017 at 21:36 Comment(7)
While this answer is partially true, allowing merges from specific branch makes it easier for quality control. e.g. if your org follow git-flow, then this can be easily practiced by only allowing merges from certain branches to protected branches. This reduces cognitive load for the PR reviewer by automating these small details. For exceptional situations you can always request override from the admin.Penland
@Penland I don't dispute that - this is providing an alternative perspective and therefore an alternate solution. Whether this approach or another is better will depend on a lot of factors. It sounds like you have a working system to automate this - perhaps provide an alternate answer?Saprolite
@Saprolite I was looking for the same, seems there is no way to enforce this ruleCarey
@Carey No direct way in git that I'm aware of. With Github or Gitlab, both provide branch protection and if you are using merge requests for merges, then you can require approvals and one checklist item would be making sure you are merging from the right places to the right places. My team uses a branch strategy inspired by Gitflow, and have both a develop and master branch, but we allow merges to master from primarily develop, but sometimes directly from a hotfix branch... But both develop and master require a merge request/pull request and approvalsSaprolite
Added intro section to clarify this isn't a direct answer due to all the haters (lol). While I understand this doesn't directly answer the question, it does not appear there is a direct way to do this. Some people coming here are not aware of the alternatives, which I've seen work in practice (and actively use in a large engineering organization). 6 years up and no other answer - I'm a little confused by the recent downvotes...Saprolite
The question is about pull request. Pull requests are not a Git feature. So saying there is no Git solution is meaningless. Of course there is no Git solution. But there might be a GitHub solution.Richert
@Richert Feel free to post any alternate solution as an answer. This answer does suggest Gitlab/Github features as part of the alternate solution (not purely git related answer)Saprolite
G
1

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.

Gaylor answered 13/5 at 13:14 Comment(2)
The problem is that in real life you don't know what the branch pushed to will be; it's a feature branch, the developer simply created it and gave it a name.Richert
The way the question was asked I assumed they should have at least know before hand the name of the branch they want to restrict. With GHA you can also make the "special action" run on branches that match specific pattern instead of exact matchingGaylor

© 2022 - 2024 — McMap. All rights reserved.