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.
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 found how to block/protect branch from pushes, force pushes but how to protect branch from pull requests? When somebody creates pull requests branch merges with branch which locked (f.e. master branch) without any problems or acknowledges. How to protect branch from pull request Of course if it possible?
Branch lock (protect branch from pushes);
Branch security (deny force pushes)
I want to make impossible to complete pull request to locked branch. Of course if it possible.
I tested locking a branch, the result of the test is that it can successfully prevent other users from completing the pull request and merge to the target branch.
When I lock the master branch, and then create pr from the dev branch to the master branch, when I click complete, I will be prompted to stop me from completing the pr.
In addition, locking the branch can also prevent me from committing to the locked branch.
So I think locking branch can meet your need.For details ,please refer to this official document.
Plainly block branch from any PR isn't possible as a singular feature. But you can use branch policies to achieve something alike.
ADO docs says you can set policies:
Add specific person as required approver (it can be you)
Require minimum number of reviewers (you can add 999 person)
Check for linked work items
Require approval from external services (via API)
Plain locking branch forever and whatever happens is not the best approach (you want to have opportunity to do that sometimes). Hope that helps.
Hm strange. Because in our case lock not preventing from PR.
Probably it depends on who made PR. His privileges in Project but I'm not sure...
master branch lock
successfull PR
Can anyone explain why a commit in GitHub would display the following information : 'Contributor-A' committed with 'Contributor-B' on 15 Feb.
Does it mean that 'Contributor-A' is the author (who does not have the push access to the master) and 'Contributor-B' is the committer/maintainer?
Then why isn't there a PR created for merging this commit? Or does it mean that there was a closed PR about this commit, but the maintainer did not merge it via web interface but performed rebase or cherry-picking to include it?
Many thanks!
...maintainer did not merge it via web interface but performed rebase or cherry-picking to include it?
I was able to get this by cherry-picking a commit from another branch and directly pushing to the current branch - an example on GitHub.
A Pull Request is not required to push code between branches. A Pull Request is a method that allows developers to collaborate on changes prior to merging between branches.
For sure, it happens when the pull request was merged by "Rebase and Merge" strategy via the web interface, but I'm not sure if this is the unique case.
Contributor-A committed with Contributor-B on 15 Feb.
Contributor-A submitted the pull request and Contributor-B effectively merged it.
It might happen in other scenarios as described here: how to apply a git patch as if the author committed to my repo?
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.
I have 2 branches - master and develop
I have been doing some pull requests in my develop branch where it contains 5 items, in which it is the same as the number of items in master.
However, someone did some commits and pushed in a few more items into the master branch, and hence now it has 8 items.
As my pull request in the develop is still not yet approved/merged, whenever I tried to update my pull request, I am getting the message stating that This pull request can't be merged. You will need to resolve conflicts to be able to merge and asked me to do the following:
git fetch origin master
git checkout develop
git merge FETCH_HEAD
git commit
git push origin HEAD
And this happens after I have 'pushed' out my commits, making me confused at times. Then I realized that it is asking me to re-add and re-commit in the additional 3 new items. So does this means I must ensure that the items and contents between these 2 branches of mine should be the same as always? I have always used git pull/fetch but will there be a better way for me to make sure?
What this means is that GitHub would like to merge your PR branch into master, but it can't, because there are conflicts. As you've discussed in the question comments, the best way to deal with this (usually) is to merge your master branch into develop on the command line. That will show you the conflicts and ask you to resolve them. Once you've completed and pushed that merge, the PR will be mergeable back into master using the green button on GitHub.
You could simply merge your deploy branch into master (which I realize sounds a bit more sensible). In that case, you'd be bypassing the PR entirely. You'd have to close the PR "unmerged", and separately you'd manually push the merge commit to master.
By doing it the first way,
you make a better audit trail by merging to master on GitHub, using the PR;
you give your team a chance to review your code after the merge, before it lands on master; and
if you have automatic tests (such as Travis CI or CircleCI) which check PRs, you give them a chance to run your merged code as well.