Answers: <p>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. </p>
  
  <p>One feature that is likely to help is “branch protection settings” on this <a href="https://help.github.com/articles/about-protected-branches/" rel="nofollow noreferrer">protected branches article</a>. You can state that only code reviewed PRs are allowed into a branch. See also <a href="https://help.github.com/articles/about-codeowners/" rel="nofollow noreferrer">About Code Owners</a> where some users can be named as the code owners on a particular branch. Only they can accept changes to the branch. </p>
  
  <p>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.</p>
  
  <p>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. </p>
  
  <p>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.</p>
  
  <p>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. </p>
  
Answers: CC BY-SA 4.0
Answers: 2018-12-12T06:51:19.653Z
Answers: 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.
Answers: Rajesh Rajendran
Answers: CC BY-SA 4.0
Answers: 2018-12-12T07:17:50.973Z
Answers: 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.
Answers: simbo1905
Answers: CC BY-SA 4.0
Answers: 2018-12-12T07:22:09.130Z
Answers: 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 https://help.github.com/articles/about-pull-request-merges/
Answers: simbo1905
Answers: CC BY-SA 4.0
Answers: 2018-12-11T22:14:08.703Z
Answers: 2018-12-11T22:14:08.703Z
Answers: simbo1905
Body: <p>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. </p>
  
  <p>Is there any better way to do that?</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-12-11T16:27:37.473Z
Comments: A branch? Github flow is about merging a branch into master.
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2018-12-11T16:50:54.113Z
Comments: I didn't say github flow. It's a custom workflow, kind of trunk based development.so direct commits.
Comments: Rajesh Rajendran
Tags: <continuous-integration><git><github>
Title: GitHub merge access
UserDisplayName: Rajesh Rajendran
ThreadText: # GitHub merge access
  
  (Asked by: username_0 on 2018-12-11)
  
  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?
  
  **Tags:** continuous-integration, git, github
  
  > **Comments:**
  > **username_1**: A branch? Github flow is about merging a branch into master.  
  > **username_0**: I didn't say github flow. It's a custom workflow, kind of trunk based development.so direct commits.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-12-11. Score: 2 | Accepted answer
  
  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](https://help.github.com/articles/about-protected-branches/). You can state that only code reviewed PRs are allowed into a branch. See also [About Code Owners](https://help.github.com/articles/about-codeowners/) 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.
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_2**: 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.  
  > **username_2**: 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 https://help.github.com/articles/about-pull-request-merges/  
  
  ---
  
  