Current Articles | RSS Feed RSS Feed

Put Down Your Forks - Introducing Protected Branches

Posted by Titas Norkunas on Thu, Mar 21, 2013
  
  
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.

Tags: , , , , , ,

COMMENTS

Really great feature. Thank you. We are using it already to prevent check-ins against released versions to avoid confusion in troubleshooting. We'd also like to use it to prevent other teams from committing code to projects they ought not to. 
Along those lines, one nice-to-have would be to expose svn groups so that you could protect a branch from all but a group of users without having to name those users individually. 
But again, the "as-is" functionality is meeting our need. Thanks.

posted @ Friday, March 22, 2013 11:10 AM by Jeff Kavanagh


Jeff, currently we allow only groups by permission type - "Owners, members, watchers" or individual users. In the future, we will add groups from the team page.

posted @ Monday, March 25, 2013 8:42 AM by Titas


The protected branch used to allow someone not in the permitted list to "Merge and Close" a merge request while still preventing them from pushing direct to the branch with git. We found this distinction useful. Ideally I would like no one to have permission to push directly.

posted @ Wednesday, April 03, 2013 7:43 AM by Mark Thornton


Alternatively, allow some developers to Merge and Close if the request has received sufficient votes from other developers.

posted @ Wednesday, April 03, 2013 7:46 AM by Mark Thornton


Mark, we are working on an improvement for this - you will be able to check one more checkbox to enable the Mandatory Review use case easier - anything that is pushed to protected branch will instead get pushed to another branch and a merge request will automatically be created

posted @ Thursday, April 04, 2013 5:40 AM by Titas


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Get Started

blog CTA button

Subscribe by Email

Your email: