12

Is there a way of setting up a branch such that it can only be merged into, rather than pushed into? Furthermore, is there any way that works on BitBucket, GitLab or GitHub?

We work on feature branches, push those to BitBucket/GitLab/GitHub (depending on the project), and then merge them into an integration branch called 'development'. I want to prevent people from being able to push directly to 'development'.

BitBucket has a means of restricting access to branches, but it also prevents people from being able to do merge requests too.

DeejUK
  • 12,891
  • 19
  • 89
  • 169
  • 1
    Technically, a merge is just a commit with multiple parents, which you will still need to push somewhere if you want to publish it. – poke Oct 14 '13 at 11:18

2 Answers2

13

Yes: it is called forking (as in GitHub fork and its tips, BitBucket fork and GitLab fork).

  • You have one repo where only an integrator is in charge (he/she will merge into the destination branch).
    The developers cannot push to that repo.

  • You have "forked repo", from where you can make pull requests to the original repo: contributors can push to any branch they want, and then make (from that pushed branch) pull request to the destination branch of the original repo.

forking

In theory, you could use only one upstream repo, but that would require an authorization layer like gitolite in order to protect branches against push/merging.
That isn't available at Github (which doesn't protect branches), BitBucket (which protects branches, but not against merges), and GitLab (same than BitBucket).

This is why it is easier to work with several upstream repos: an original one, and one or several forks.

And GitHub/BitBucket/GitLab have a nice interface around pull requests, tying those with comments, facilitating communication and discussion around a particular pull request.

Forking + pull request isn't just "the git way", it really is the most convenient way to integrate many contributions, which is why git was invented by Linus Torvalds in the first place: help him integrate a lot of patches a day for his Linux kernel.

The "protected branch" approach mentioned by Tippa Raj (and that I mentioned just above) isn't an approach I would recommend, as it would artificially enforce a centralized approach, where you need to control everything:

  • the branches to protect
  • the branches you allow to be published: with one repo, developers would be tempted to push all their branches.

GitHub doesn't provide protected branches for that reason.
(Actually, since Sept. 2015, it does: see "How to protect “master” in github?")
BitBucket and GitLab do provide that feature.

Individual repos can also manage and protected branches (even folders and files) with the addition of an authorization layer like gitolite.

But when it comes to facilitating collaboration around feature branches, nothing beats pull requests.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks, that's a very thorough answer. I fear multiple upstream repositories are an abstraction too far for the cases in hand - may just be easier to beat people with the Naughty Stick when the push somewhere they shouldn't! – DeejUK Oct 14 '13 at 13:11
  • @Deejay no, it isn't an abstraction too far, it is really how a *distributed* VCS like git is supposed to work. – VonC Oct 14 '13 at 13:27
  • 1
    @Deejay and it is how both GitHub, BitBicket and GitLab address that "fairly common requirement". – VonC Oct 14 '13 at 14:04
  • Thanks - some of the developers on the project are very new to Git, and merge requests are a challenge for them: hence my remark that it's an abstraction too far in this case, even if it is the 'right' way of doing it. – DeejUK Oct 14 '13 at 14:34
  • @Deejay I understand. That is why I do explain what fork (http://stackoverflow.com/a/6286877/6309) and pull request are on Stack Overflow. Challenge resolved ;) – VonC Oct 14 '13 at 14:39
  • The forking workflow though has implications: for example often shops will have normalized environments where the code is automatically checked out for devs on a VM. If that checked out env is to be a fork, that's a lot more complex to set up than a simple clone of the "main" repo. – Adam Parkin Mar 20 '15 at 20:53
2

Apart from Fork and Merge, there is another way.

I am Not sure about Bitbucket and Github, but Gitlab has a feature where you can protect a branch. So no push can happen to that branch by anyone other than the "Master user". So Developers can push into feature branches, and the branches can then be merged into master branch by the "Master user"

Tippa Raj
  • 584
  • 4
  • 8
  • Bitbucket has a similar mechanism with Branch restrictions: https://blog.bitbucket.org/2013/09/16/take-control-with-branch-restrictions/ – Adam Parkin Mar 20 '15 at 20:51