How to restrict access to the master branch in Git

Question

I have a single repository in which I have two user groups:

• Administrators
• HTML/UI Developers

I do not wish to give read/write access of my master branch to my HTML developers as they do not need to work on it and should not be misusing the core code.

Though they need to work on their own branch ui-developers. How do I do this on Git?

P.S.: I am using Bitbucket

---

I had posted this question when I was extremely new to coding and Git. After two years of experience, I now know that Git doesn't allow to restrict READ access for any particular branch. But services like Bitbucket, GitLab, and GitHub allow you to put write and merge restrictions to branches.

Also, I shifted to GitLab six months back :)

Solution 1

Git itself does not have such feature, but many hosting providers do. This is generally known as branch protection. There is no way to prevent read access as far as I know.

Using Bitbucket

Bitbucket allows a lot of customization for the actions to prevent by branch protection. To protect a branch:

1. Go to a repository in a project.

2. Choose Settings → Branch permissions.

3. Click Add permission.

4. In the Branches field, select either Branch name, Branch pattern, or Branching model.

• Branch name - select an existing branch by name.

• Branch pattern - specify a branch using branch pattern syntax for matching branch names.

• Branching model - select the branch type to restrict access to.

5. Select the type of actions you want to prevent.

• Branch deletion - prevents branch and tag deletion.

• Rewriting history - prevents history rewrites on the specified branch(es) - for example by a force push or rebase.

• Changes without a pull request - prevents pushing changes directly to the specified branch(es); changes are allowed only with a pull request.

• All modifications - prevents pushes to the specified branch(es) and restricts creating new branches matching the specified branch(es) or pattern.

6. Optional: Add exemptions for any of the selected restrictions. Adding a user or group as an exemption means that it will not apply to them. This is not required; not adding any exemptions means the restriction will apply to everyone.

7. Click Create to finish.

Source

Using GitHub

A repository can have multiple protected branch rules that affect the same branches.

Protected branches are available only in public repositories with GitHub Free.

Protected branch in GitHub can be configured to require:

• pushes to be made via pull requests and reviewed before being merged,

• other branches to pass status check before being merged,

• commits to be signed,

• history to be linear,

• that the above rules are enforced even for administrators,

• that pushes come from specific people, teams or applications,

Force pushes and deletions can be allowed independently.

To protect a branch:

1. On GitHub, navigate to the main page of the repository.

2. Under your repository name, click Settings.

3. In the left menu, click Branches.

4. Next to "Branch protection rules", click Add rule.

5. Under "Branch name pattern", type the branch name or pattern you want to protect (Impacted branches are listed and counted).

6. Configure specific branch rule settings if needed.

7. Click Create or Save changes.

Source

Using GitLab

In GitLab, protecting a branch does the following:

• it prevents its creation, if not already created, from everybody except users with Master permission
• it prevents pushes from everybody except users with Master permission
• it prevents anyone from force pushing to the branch
• it prevents anyone from deleting the branch

To protect the branch:

1. Navigate to the main page of the project.

2. In the upper right corner, click the settings wheel and select Protected branches.

3. From the Branch dropdown menu, select the branch you want to protect and click Protect.

4. Once done, the protected branch will appear in the "Already protected" list.

You can then allow some access to users with developer rights by checking "Developers can merge" or "Developers can push"

Source

Solution 2

Actually for Bitbucket, you can add a branch permission for Master only to block everything:

And then for feature, you do allow writing to feature branches:

I have tested it and I am not allowed to push directly to the Master branch.

Solution 3

In Git itself you can use the "pre-receive" hook in the server to protect for writing in a branch to some user.

Using this hook you can apply your restriction policies for each file in the push.

Here you can find an example.

Solution 4

Addition to @1615903's answer, you can protect a branch in Azure DevOps like below:

Using Azure DevOps

In Azure DevOps, protecting a branch with security permissions and policies which allow you can do the following:

• Add or remove users and groups to a specific branch.
• Declare a minimum number of reviewers for pull requests.
• Automatically include code reviewers
• Automatically check linked work items is required or optional
• Check for comment resolution
• Enforce a merge strategy (no-fast-forward or squash)
• Build validation

and more detailed information on the documentation page.

To protect the branch:

1. Select Repos → Branches in the project's main page to open the Branches.
2. Locate your branch on the page in which all branches are listed.
3. Select the ... button. Then select Branch policies or Branch security from the context menu.
4. Once you have done, select Save changes to apply your new policy configuration.

Solution 5

There is a lot of information here that is factually incorrect today.

Protected branches are not "only" limited to GitHub public branches. Can you restrict read access to a branch? Yes! You can restrict read access using key management, namely SSH keys. We do it all of the time given we have contracting software developers working on projects that don’t work for us.

Essentially if you don't authenticate with the issued SSH key, you can’t access (read/write) the branch. We later got smarter and started asking each developer to share their SSH key with us and we developed a script now (for Bitbucket) that checks against all SSH keys before granting access.

View more solutions

Comments

[John Zwinck]

Simplest is to just tell them what you want them to do.

[Harshit Agrawal]

@JohnZwinck Would prefer 'restricting' it in stead of just relying on everyone to follow the instructions

[Gotts]

Did you ever manage to do this? I need to do the same

[Harshit Agrawal]

Hi, no. I wasn't able to do this as it is still not possible from git

[user85]

You can't control read access to your project/group members (in this case HTML/UI developers) but you can certainly have write control on master. You can protect master by not allowing to commit and allow only Maintainers or Maintainers /Developers to Merge request to master. That way every developer with their own ui-developers branch need to review code before merging to master when required.

[Abdo]

So how to restrict WRITE access (push)?

[Somendra Meena]

The steps for GitHub seems to have updated since you answered. Can you please update your answer as per the latest update.

[Noumenon]

I was curious about "Branching model" in Bitbucket -- it seems similar to "branching pattern" in that it lets you do restrictions to all branches named "feature/", "development", and so on. confluence.atlassian.com/bitbucketserver/…

[Mike]

All of the buttons on the master branch policies page are disabled even though I am the one and only admin.

[RTD]

On GitHub: "Protected branches are available to Pro, Team, and Enterprise users"

[1615903]

Don't know where you got that quote, but this is what GitHub website says: "Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server."

[user276648]

Could you explain a bit more how you do it?

[Peter Mortensen]

What kind of SSH key? Private or public key? Can you add it? (But without "Edit:", "Update:", or similar - the answer should appear as if it was written today).