I am working on a repo where I am the owner and only author in it.
I want to have in my repo the same behavior as I would when working with a team that protects my branch from direct commits as they must go through a Pull Request. The reason for doing so is to protect from my own mistakes as I sometimes go back to main branch and accidentally push code to it. I want only code that passed through a Pull Request to be able to be merged to main branch.
In order to achieve such behavior I added the following rule to my main branch -
Which is almost what I need, expect that I am locked without the ability to approve my PR's as there is a message I get saying authors of the PR can't approve their PR's - a logical error nonetheless, but if I am working alone in the repo this is not what I am looking for.
How can I achieve what I am looking for?
Simply disable "Require approvals" (the second checkbox in your screenshot), you will still be required to create a PR.
You can merge your own PRs, the only thing you cannot do is to approve your own work (after all: why would you? Hopefully you deem your own changes good!)
Related
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).
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.
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'?
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.
I am looking for a way by GitHub setting or CircleCI settings preventing the person that is involved in PR (create PR or make a commit) to be able to merge PR (or even approve it).
So far I have the protection of a branch that requires approvals but post-approval I as PR creator and committer I still able to merge.
You need to be able to
prevent the person that is involved in PR (create PR or make a commit) to be able to merge PR (or even approve it)
A contributor who has created a PR cannot approve or request changes by default in GitHub, so that is already taken care of.
Since a Pull Request is a GitHub feature, a PR merge can currently only be blocked by 2 ways
Using GitHub's settings
Using pre-receive hooks (only for GitHub Enterprise)
Using GitHub's settings, you can only block merging by requiring either pull request reviews, status checks to pass, signed commits or linear history as shown under the branch protection settings.
or by allowing merge commits, squash merging or rebase merging as shown in the Merge button section under repo settings
If you are on GitHub Enterprise, you can use a pre-receive hook (documentation) like below and ensure that self merging PRs are blocked (This eg is here)
if [[ "$GITHUB_VIA" = *"merge"* ]] && [[ "$GITHUB_PULL_REQUEST_AUTHOR_LOGIN" = "$GITHUB_USER_LOGIN" ]]; then
echo "Blocking merging of your own pull request."
exit 1
fi
exit 0
Apart from the above, there is no other way currently to block self merging PRs on GitHub. And using CircleCI or any other CI workflow can only block merging for everybody(if you opt for the requirement of status checks on GitHub) or nobody, as it can't control the PR merge button.
Greeting! The short answer is no. Now the longer answer! GitHub supports enabling master branch protection. This can help you enforce all kinds of rules like:
All PRs must have a code review before being merged
The reviewers of the code need to be an admin
The reviewers of the code need to be in a CODEOWNERS file
A subset of status checks all need to pass
For all of these rules, the assumption is that once they've been satisfied, anyone with write access to the repository can merge the PR. I'm curious - in what situation do you want to prevent that?
Now onto the bad ideas. If this was super important - you could take the drastic step of ensuring no human is responsible for merging PRs :) You could add a codeowner that is mapped to a robot account, ensuring that robot account performs an approval before the PR can merge. To that end, you could write logic in a custom GitHub action that's triggered on PR events to determine if the PR should be merged, and auto-merge it if all appropriate conditions are met.
I'm curious - why is this something you wanna do?
I've built an Action to provide this; should work on GitHub.com, GHEC, and GHES: https://github.com/marketplace/actions/dismiss-code-reviews-from-collaborators
As always, Issues & PRs are welcomed: https://github.com/peckjon/reject-pr-approval-from-committer
As repo reviewer you’ll get PR, review the code (semantics) and Github will simply check about merge ability of the changes.
If a (remote) collaborator works on a outdated master branch will potentially have positive feedback from tests. But might have hidden semantics issues or might break tests when merged on the latest master commit (hopefully at CD's pipeline test phase and before going to prod).
Said so, I agree that it’s always up to the reviewers to ensure that the PR should not break.
But I’m also thinking, why not helping the reviewer by warning that you are currently merging changes starting from a branch that is behind X commits from master?
Does it make sense? Or maybe there’s already something (invisible to me) that might alert us inside a PR UI about it?
P.S. I understand that.... if the above is confirmed this is not going to be a real question but a feature request to Github... but I think it's worth questioning about this.
You can make the master branch protected and require that the branch in the PR be up to date before allowing a merge. The GitHub documentation describes how to do this.
How do I go about making my pull requests have only the changes made on the new branch? Every time I push a branch it has all the changes from the previous branches included in the pull request also.
My manager is really big on making sure we do small PRs and have only the new changes on each one for easy review, but I'm at a complete loss as to how to do this. This is my first dev job and up until now I unfortunately haven't been able to do group work so managing PRs that might be a while before they are merged in is totally new to me.
So far I've only found how to cherry pick commits, is this the only way?
If I understand you right, you have a main branch (master?) that contains the latest version of your software and you have one or more other branches that contain modifications. You do some more modifications in that other branch and if you create a pull request it will contain all other changes.
The most simple solution I can think of is to use dedicated branches for all changes. Before starting to work, create a new branch from the main branch with the ticket ID, work description or whatever you use to describe your work: git branch -b feature-123.
Commit to this branch only and push it to the repo. If you now create a pull request from this feature branch to the main branch, it will only contain the changes you did and nothing else.
The further pull requests highly depend on your internal workflow and branch structure. But basically this workflow applies to all new changes.
I may have screwed up, but there a way to get a code review going on GitHub after I did the below workflow?
I cloned a remote repository, branched the master and made my changes. I committed the changes, merged my branch into master, then ran a sync on GitHub and the changes are there now.
I'd now like to initiate a post-checkin review, but didn't fork the repository and so can't initiate a pull request, which as I understand it now is the common way to get reviews going in github. What should my next steps be?
Next time you should just push your changes from your branch to the remote repository, then submit a "pull request" for the branch back into master where the code can be reviewed prior to merging.
When you push changes to your branch, to compare your changes, go to that branch and look for this near the top in the code tab:
This is some good reading as well about how/when to use forking & pull requests: https://help.github.com/articles/using-pull-requests
EDIT:
And since you did say this is after the fact, the other thing you can do is go to the master branch->commits section, and click on the commit where you merged your branch in. That page allows you to make comments and view the changed files, so you can still review your code before you actually push it to your server. However, you should still do the other way next time.
To clarify...you can branch locally and then change, commit etc, and then push that branch to GitHub, then fire off a pull request?
Yes, and since August 14th 2018, you don't even need to switch to the Code tab:
When you push branches while using the “Pull requests” tab, GitHub will now display the dynamic “Compare and pull request” widget—so you can quickly create a pull request without having to switch back to the “Code” tab.
Learn more about pull requests in our documentation.