Put Down Your Forks - Introducing Protected Branches

Posted by Titas Norkunas on Mar 21, 2013 4:07:00 AM

Lets talk about forks. They are so awesome for open source. Why?
  • A fork is a natural way to give external contributors a place to work
  • Really, that is the main reason to fork
Look at the open source projects more closely. Only the external contributors - who are not part of the core team - work in forks. The core team members work with the main repository in branches.

A company does allow their developers to commit to the repository. A company does not want everyone to be able to merge to a release or master branch, using a fork for this is an over-complicated workaround:
  • Developers need to maintain forks
  • Additional setup to CI is required
  • Whenever a change to the repository configuration is made, it needs to be made in all forks (for instance installing a webhook)

Does it have to be so difficult? Not at all. Here is where Protected Branches are awesome and a clean solution to this problem.

A Protected Branch is a branch with limited write access. Specify members (or groups) of your team that will be able to submit code to a branch:

Protected Branches

Now, only these people will be able to push to the Master branch. Everyone else will have to contribute code through merge requests. They will be able to push to any other branch in the repo, but not Master.

Protected Branch

Protected Branches enable various common techniques - mandatory review from a senior developer, release manager that maintains release branches, feature freeze a release candidate. We have no doubt you will find even more use for it.

Sometimes you just have to leave that Social Coding aside and get some work done.

Topics: development process, git, repositories, subversion, git/gerrit, workflow, renzoku

Written by Titas Norkunas

Follow Assembla

Get Started

blog-CTA-button

Subscribe to Email Updates