How can you stop a branch being accidentally deleted in a pull request?
The issue is the "Complete pull request" has got the "Delete dev after merging" check box, and this seems to be checked by default, which may be because I'm the owner of the repos.
Is there someway to disable this for all users?
For now, there is no way to disable the Delete source branch after merging option.
And there is an user voice Disable Delete Branch Checkbox in PR When Branch Policy In Place which suggest similar feature, you can vote and follow up.
The workaround is set branch security for the target branch (dev branch for your situation):
In VSTS Branches Tab -> click … button for dev branch -> Branch security -> change Force push (rewrite history, delete branches and tags) as Deny for the users and groups -> Save changes.
BTW: Delete source branch after merging option in PR completing window is not checked/selected by default, but based on the last time's setting. Such as if you deselect the option now, when you open the PR completing window next time, the Delete source branch after merging option will be deselected.
See this post. You just need to add a policy to the branch, then it cannot be deleted.
I may be a bit late on this thread. I faced this problem and found solution in Azure Dev Ops. While approving you get option to deselect.
Related
I'm trying to prevent developers from directly editing and committing to the master branch in ADF.
There is a risk that users can accidently make changes in ADF by not creating a feature branch but instead working directly on master (I've done it myself!)
Is there a way to enforce this in ADF? I do have a branch policy on master that only allows merging via a pull request but don't think this stops developers from working directly on master:
Another way to achieve this is to require a reviewer.
Select "Branch policies":
Turn on the option "Require a minimum number of reviewers":
Set the number of reviewers to 1.
This example shows "Allow requestors to approve their own changes". This setting is optional. If you set it, the user is still prevented from committing to main/master, but can complete their own PRs.
You can deny the contribute permission for the user group in git repo. Check the following official documentation:
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-permissions?view=azure-devops
We are using git repositories with our azure dev-ops setup.
I have a couple of branches that I've worked on a lot, but we are having to put a pause on the work for now as other items have become more important. I want to make sure these branches are not deleted accidentally. My permission setup is a little higher than some of the other developers. Is there a way to put a lock from deleting the branch from the Collection -> Repos -> Branches?
Right now I go to More Options -> Delete Branch and it will ask before it is deleted. I want to put a lock where if you say Delete to Branch feature/testbranchdelete will be permanently deleted. Are you sure you want to proceed? that it will stop it from being deleted.
Thanks.
I have tested according to your narrative and found that the locked branch could still be deleted. And after I changed the Branch Security Permission, the test branch was unable to be deleted.
Please use a new branch in your Repos for the test of this operation following the marks in the picture below. Define Individual and Group Users as Force push (rewrite history, delete branches and tags) -> Deny.
After approving a PR, can a reviewer be allowed to delete the source feature branch (during merging)? feature branch is created off develop branch. We want reviewer to be able to delete feature branch. However, reviewer should not be able to delete develop branch while merging that to master branch.
Is that possible with Azure DevOps? How can we set the branch policy/security to achieve the above?
Addition: feature branch can indeed be deleted provided branch owner is the one completing the PR (there is a checkbox to do that). We want to shift that responsibility to reviewer who does not really own the feature branch. (The checkbox is disabled for reviewer with insufficient permissions message.)
To enable the reviewer the permission to delete the branch, you need to enable the delete branch permission in the Repositories' setting. Please check below steps:
Go to Project settings -> Repos -> Repositories -> Select your repository.
On the Security page of your repository, Search the user you want to grant the delete branch permission in the search box.
On the Security page of the selected user, Set the Force push permission to Allow. Then the delete checkbox for the reviewer will be enabled.
Update:
If you want to enable multiple reviewers the delete permission. You can go to Organization settings, click Permissions under Security, Click New group to create a new Group(eg.Reviewers) and add the reviewers to this group.
Then follow above steps enable the branch deletion permission for this Group. The reveiwers in this Group will automatically inherit this deletion permission.
Having any branch policy on develop would mean that it can't be deleted when completing a PR to master. Branches with policies set are inelgible for deletion as part of PR completion.
It seems to me that you can only see the vulnerable dependencies on the master branch. I fixed those mentioned in the alert on a separate branch and want to check if in fact the vulnerable dependencies are fixed, so what I really need is to be able to check the alert for the specific branch, can this be done?
I had this same issue.
The problem with GitHub's Security Alert feature is that it will always scans the default branch of a repository. This is normally the master branch. Therefore, any changes to resolve security issues made to other branches will not be recognised by GitHub.
The workaround.
You can change the default branch to be any branch in your repository! Including the one you have done the work to resolve the security issues.
On GitHub, navigate to the main page of the repository.
Under your repository name, click Settings.
In the left menu, click Branches.
Choose the new default branch.
Once you have changed the default branch to the branch you have done the resolving work on, GitHub's Security Alert feature will start to scan that branch.
And you should see the security alerts that you have resolved disappear.
Afterwards you can change the default branch back to the master branch and only change it when you are specifically working on resolving security vulnerabilities.
The security alerts for vulnerable dependencies reported by GitHub might be valid only for the default branch (usually master, but you can change it).
If you are not ready to merge your fix to the default branch of your repo, one workaround would be to push that branch to the default (again, usually master) branch of a new dedicated (and temporary) repository, just to check if any new alerts are detected on that new repo.
Update Oct. 2020, 2+ years later: Michael Greisman points out in the comments to this GitHub Community answer and the documentation "About alerts for vulnerable dependencies".
It confirms that the scan is done against the default branch.
"Once the fix... is merged into the default branch... GitHub will schedule a new scan of your project’s dependencies".
If I fork a repository I have permission to that is owned by a company into my personal github, make some changes, make a PR, sometimes my collaborators (the ones in charge of the PR) will click "merge and delete local branch". This deletes the branch out of my private github account. Is there a way to disable this?
If there is no way to disable it, a workaround would be to create a branch referencing the same HEAD as the feature branch used for the PR (and which gets deleted when merged in the original repo).
That would allow you to keep track of that feature branch, even after the PR has been completed.