I have a VSTS/Azure DevOps project with a git repository containing different customer branches. I would like to permit each customer to read-only their own branch. How can I achieve this?
The access control settings do not allow me to set read permissions on specific branches, only on entire repositories. So is it perhaps possible to have a separate repository for each customer that automatically mirrors just the corresponding branch in the master repository?
You can't specify the permission directly in branches (branch level). However, you can inherit/modify the permissions from the repo level to branch level.
See my similar answer here
As you stated in your question. You should create separate repos for different customer where you can control the permissions.
Related
User from a group like Build Administrator can access the project from Azure Devops. I need to control the user in that group to upload the file directly to the master branch. The user can manually upload files to all branches except Master. Because my master branch is based on Pull request. How can I implement this? Does it need any permission?
There are a few critical branches in your repo that the team relies on always being in good shape, such as your master branch. Require pull requests to make any changes on these branches. Developers pushing changes directly to the protected branches will have their pushes rejected. Thus, following this doc: Improve code quality with branch policies to protect your master branch.
In addition, be reference to this doc: Allow bypassing branch policies without giving up push protection, please note that these 2 permissions(Bypass policies when completing pull requests and Bypass policies when pushing) shouldn’t be granted to your mentioned Build Administrator group for master branch. See: Set branch permissions for details.
As soon as you enable any policy on your default branch changes must be made via pull request.
From the branch policy dialogue
Branch Policies: Note: If any required policy is enabled, this branch cannot be deleted and changes must be made via pull request.
So to disable direct commits follow these steps:
Navigate to project settings (cogwheel)
Repositories > select your repo
Navigate to Policies
In the Branch Policies section select your default branch
Enable any policies that make sense to your use case. Require a minimum number of reviewers might be a good starting point.
Just to understand,
You want to allow your user to store their files on the master branch ? Which tool are they using to upload ? Visual Studio or just drag & drop ?
Anyway you can have some settings on the azure devops by going on
Azure Devops ---> Your Repository --> Branches --> Select the branch you want to modify and click on the 3 dots (...) --> Select Branch Policies
In the azure doc it is recommended to use as few projects as possible in one organization.
Now I have the scenario that I need to restrict read access to certain Git repositories.
How would I accomplish that?
From what I have seen in the documentation and devops itself I have the feeling that I have to create a dedicated project and restrict the access to the project to which those repositories belong to.
If I now see the URL of a Git repo I cannot even see the project name at all. Does that mean that GIT repositories belong more to an organization than to a project?
Thank you for your support
Git repo belongs only to a project. To restrict access you can:
Create new security group: Project-level groups
Add it into Git repo groups and deny Read access. Set Git repository permissions
I want to set up a proper workflow on GitHub where junior engineers submit pull request for code review and only the lead engineer can commit to the master branch.
I'm looking for input from professionals that work in a commercial software environment. I've found the page that does the permissions easy enough. There are several options. Restrict who can push to matching branches of course. Should I check others as well?
The other approach, beside the branch permission within one repo, is the gate repo:
you are setting up a public repo where developers can commit (on master or topic branches)
you are using a private, or repo within an organisation, from which you can pull
That way, you or your organisation team control the contribution you chose to include in the master of that main repository.
In github, my account can access multiple related repositories. A user story can be implemented as same-name branches in multiple repositories.
Given a branch's name, can I find out which repositories contain a branch with the given name?
Can I further jump to such a branch in a given repository?
Probably the simplest way of searching repositories for branch names is to use the command git branch within each repo. You can specify git branch -a for local and remote branches, or git branch -r for just remote.
This isn't ideal for a number of reasons, one being that you'd need to have command-line access to all the repositories you want to search (such as all the repos being cloned locally), another being that you'll have to manually scan through the branch list that git branch outputs.
One possible solution to this is to use the GitHub API to list all repos and / or all branches. The answer here gives a decent example in Python of how to authenticate (to allow access to private repos), which you would need to follow with the API's GET request:
GET /repos/:owner/:repo/branches
I was added as collaborator to a public GitHub repo and I was able to make changes to the main branch. A pull request was not generated, the changes just went right in. I am using Visual Studio 2015 as my client, for what it's worth.
Yes, it depends on the permission.
There are 4 types of permissions:
Read
Write
Admin
Owner
Note: Organization members with owner permissions have extensive permissions across all repositories in an organization.
See the permissions and associated actions at Repository permission levels for an organization and Collaborator access on a repository owned by a user account.
Yes, it is either your responsibility to properly follow process (i.e., create a branch and then create the pull request to merge to master / release / etc) or/and up to the repo owner to set up permissions so committing directly to master is not possible.
Yes, that's basically what collaborators are. :)
See Github - Collaborator access on a repository owned by a user account
Often, even if you have collaborator access/rights, you can choose to adopt a more kosher Git workflow, like creating a branch and a pull request for each 'thing' that goes into the main branch.