Menu
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.
627
To merge branches locally, use git checkout to switch to the branch you want to merge into. This branch is typically the main branch. Next, use git merge and specify the name of the other branch to bring into this branch. This example merges the jeff/feature1 branch into the main branch.
Go to your project and select Settings > Repository. Expand Protected branches. From the Branch dropdown menu, select the branch you want to protect. From the Allowed to merge list, select a role, or group that can merge into this branch.
In GitHub Desktop, click Current Branch. Click Choose a branch to merge into BRANCH. Click the branch you want to merge into the current branch, then click Merge BRANCH into BRANCH. Note: If there are merge conflicts, GitHub Desktop will warn you above the Merge BRANCH into BRANCH button.
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:
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.
124
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
