Github only allow collaborators to push changes via pull requests

Viewed 1528

New to GitHub, I have created a remote PRIVATE repository called X, and have a collaborator -person Y. Currently, person Y can simply accept the invitation to be a collaborator, and without forking the repo, simply make an edit, commit changes, and it appears on the master branch. This is obviously undesirable and it seems nonsensical that this is even allowed by default.

I would like person Y (collaborator) to:

-have to fork the repository and work only on the forked repo

-have to make changes ONLY via a pull request

-have to have a pull request, accepted/approved by me, before it is committed to master.

I looked through some answers, and tried: -going to settings -going to branches (on the left) -changing access rights

I noticed however, that it required an upgrade.

I am certain I have heard/read that GitHub allowed full features for up to three collaborators.

Other similar questions on SO, have 0 answers.

I have also seen this option in settings:

"When merging pull requests, you can allow any combination of merge commits, squashing, or rebasing. At least one option must be enabled. If you have linear history requirement enabled on any protected branch, you must enable squashing or rebasing."

Allow merge commits Add all commits from the head branch to the base branch with a merge commit.

It isn't clear to me what the above is referring to. If I checked that, would it stop all commits from collaborator's from being directly pushed to the master branch without authorisation?

Update:

I noticed some answers that suggested this (protecting a branch) cannot be done, but it is good practice to simply AGREE to always create a pull request. I require a pull request to be mandatory - if it is not enforced, an accidental push to master could obviously occur.

The question then is, what are workarounds for this (without having to pay).

  1. Forking? How do you 'grant' access to another user to a PRIVATE repository. I could only see the option to share access by inviting as a collaborator.

  2. There is this option which says: Default branch The default branch is considered the “base” branch in your repository, against which all pull requests and code commits are automatically made, unless you specify a different branch.

In the above case, how would I go about creating a copy of the master branch, as it were, for collaborator's to work off of, so that the actual master branch is 'protected'?

  1. The only other option I can think of is to create three levels.

One: Me: Project (with Master branch protected because I only grant access to -me 2) Two. Me 2: I am granted collaborator access and I fork the project. (call it something else) Three. I then grant collaborator access (if this is allowed) to the forked project, to someone else. This way, the collaborator can make changes to the forked project in Part 2, but not the original master project in Part 1.

Again, this all seems terribly long winded and unnecessary when all that is needed is for the master branch to be protected, only allowing pushes to master via pull requests which need to be authorised.

Any other options? Any advice or suggestions would be appreciated.

0 Answers
Related