0

I am trying to create a GitHub workflow (not GitHub flow), where specific people will have merge only access to a branch in repo. I tried a few things, and I found that I can restrict users to read and write to repo. But read access wont have merge permission, and write will have too much , like committing directly to the branch.

Is there any better way to do that?

Improve this question
2
  • 1
    A branch? Github flow is about merging a branch into master.
    – 030
    Dec 11, 2018 at 16:27
  • I didn't say github flow. It's a custom workflow, kind of trunk based development.so direct commits.
    – Rajesh Rajendran
    Dec 11, 2018 at 16:50

1 Answer 1

Reset to default
2

It’s not clear exactly what level of trust you have towards contributors. You could update your question to explain a bit more about whether people are all on one team or might be strangers.

One feature that is likely to help is “branch protection settings” on this protected branches article. You can state that only code reviewed PRs are allowed into a branch. See also About Code Owners where some users can be named as the code owners on a particular branch. Only they can accept changes to the branch.

With those controls you can set it up so that anyone can contribute to a repository but the branch(es) where release are taken from are strongly controlled.

You might consider not having people write directly to the repo if they are not trusted team members. It’s normal to have untrusted people fork the repo, add the main repo as “git remote add main $URL” and do their work on their own repo. They can “git remote pull main” to refresh from the main repo and “git push origin” to update their own fork. When they are done they can go to the web interface of their fork and creating a pull request. It will automatically be directed back to the main repo they forked. Then only writers to the main repo can merge the pull request. That is much cleaner if you really want to limit who can write to your main repo.

You can also enable “squash and merge” of pull requests so that when the PR is accepted all the commits in the PR are squashed into a single commit on the branch they are merged into.

GitHub access controls seem very permissive as “write whole repo” until you see that everyone can create forks and send PRs. When you do only have one team using a private repo then letting them push their own branches into the repo, then integrated onto a projected branch, gives good controls over what is released.

Improve this answer
3
  • Thanks for the detailed answer. 1) I am going with mergecommits rather than squash, as I want the history, 2) Figured out that if I do protect-branch and include that to administrators then only merge commits are allowed.
    – Rajesh Rajendran
    Dec 12, 2018 at 6:51
  • History is kept by “squash and merge”. The resulting commit has two parent commits, the last on the PR branch and the last on the protected branch. If you are on the protected branch and run “git log” you see the truth that all the work arrived in the squash commit. If you are on the PR branch and run git log you get the historical truth that there were many commits fixing typos and review feedback and that the squash commit made no new changes other than the comment that the PR was merged. Try it. The history of the protected branch is accurate and the history of the PR branch is accurate.
    – simbo1905
    Dec 12, 2018 at 7:17
  • and with regards to security a “squash-and-merge” of PRs it should be a new commit so as long as it is done by a trusted person so cannot be done to a protected branch by an untrusted person. see the PR documentation about it at help.github.com/articles/about-pull-request-merges
    – simbo1905
    Dec 12, 2018 at 7:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.