I have set up a git repo with protected branches in GitHub: 'main' and 'dev-*' require PRs to merge. However, all merging of other branches should be done to dev-*, and merges to main should only be done from dev-*.
I would like to set up a rule to prevent PRs into main from branches that do not match the pattern dev-*. Is there any way to do this?
GitHub doesn't provide an intrinsic way to do this, but you can always set up a CI check, such as a GitHub Action, such that it fails if the base branch is not correct. If you use a GitHub Action, you could even make it post to the issue to let the user know what's going on.
If you combine this with branch permissions that require passing status checks to merge (which are in the protected branches area), then this will prevent anyone from successfully merging from an undesired branch.
Related
I'm defining branch protection rules on GitHub, and I would like to know if is there any way to define a Pull Request flow like: qa --> main.
I know it's possible to require pull request before merging (on Require a pull request before merging flag under Branches > Branch protection rule), but I didn't find any option for defining this flow.
There's no way on GitHub to force a source branch to be fixed to a certain value, but you can solve this problem with a required CI check that fails if the PR to main has the wrong source branch. That's the usual way that people handle this sort of issue.
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
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.
Is it possible to disable direct merge to my default branch (develop)? I would like to make sure that everyone has to open a PullRequest, where we can do codeReviews, before the code could be pushed to develop.
I made develop as a protected branch, but I am not sure that's enough.
The About protected branches does include:
Can't have changes merged into it until required status checks pass
Can't have changes merged into it until required reviews are approved
That would be enough to prevent direct unsupervised merge.