Merge-only Branch on BitBucket/GitLab/GitHub?

Question

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.

Answer 1

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.

---

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.