In our git repository we have set some rules for a branch. It needs PR to merge code and needs approval from any one code owner.
A codeowner is not able to merge his own PRs. He is able to merge other peoples PRs. There is no other setting enabled that will restrict him from merging
Codeowner file looks like this,
#codeowner1 #codeowner2 #codeowner3
The codeowner has write access in the repo
I thought that he will be able to merge his own PRs since he is a codeowner. But git doesnt even ask review to him for his own PRs.
Related
Github has the option to allow a PR to be squashed when merged ("Squash and Merge")
Is there anyway I can configure the branch so it only allows the "Squash and Merge" option?
My scenario is this
we have a develop branch, that feature requests are pushed to
sometimes developers will forget to choose "Squash and Merge" and will commit their feature branch, with 10-20 tiny commits to the develop branch.
These changes eventually get merged to master, and feature history becomes hard to read
I have looked in hooks in branch protection rules, but didn't see any such option
Unfortunately the option to change what type of PR merge is available on Github is set on a per repo basis. Since PRs are a github thing, not a git thing, I can't think of a way that you'd be able to do anything with githooks either.
I don't see a great option for your workflow as long as you require the intermediate develop branch that eventually gets merged into master. Workflows that have multiple layers of PRs get messy on Github. The one real option would be that you require squash to merge on Github PRs and then the regular merge from develop to master happens outside a PR (could be local on a machine or via a Github action potentially).
But, your best option if this is really a big problem may be to modify your workflow. One common workflow would be that master is the development branch. Then when it is time for a release a release branch or tag, depending on your needs, is created from master. The you will have no issue turning on the repo wide requirement for squashing.
I'm working with hundreds of github repos (mostly Terraform) and every now and then I need to push a change all across those repos (typically version upgrade). Each has multiple branches and requires PR review before merge to master. Is there a way I can set it up so that PRs created by my automation account do not require approval before merge?
There is an hmarr/auto-approve-action action, which you can configure to auto-approve PR from certain users.
In your case, that could allow you to push as a dedicated user PRs that will be automatically approved by this action.
I want to disable commits for certain branches in github and only allow merging via Pull Requests. I can do this in VSTS Git repos, but how do I do the same in GitHub? Is this even possible?
In your repositories settings, you can go to "Branches" in the left menu.
Then you can add a "Protected Branch", and then check "Require pull request reviews before merging".
Then nobody will be able to commit on this branch unless they made another branch and submitted a Pull Request.
I would like to give merge access to my co-workers. But, I do not want them to be able to merge their code into master (or another branch I maintain: staging). Is there any way to do that?
The easiest way is to ask them to fork the repo and make PR (pull request).
You can then inspect and/or reject any PR made to the master branch.
The GitHub branch protection doesn't prevent fast-forward pushes, to the fork is the best option.
I have 2 branches in my github repository. How do I enforce a branch policy for Master branch such that any changes to it must require a code review from specific folks done ?
This is best managed by repos, not branches.
You can have one repo with the master branch, and one or several forks, from which developers can make pull request in order to request a merge to master of the original repo.
Only the "specific folks" are declared collaborators on the original repo, and can review the PRs and merge them.
Then the developers can synchronize their own fork.