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
Related
Is it possible to create an alias or redirect to a GitHub repo?
For instance, is have the repo org/my-repo, and i want that when i clone the repo org/my-repo-2 (that does not exist), the repo org/my-repo will actually be cloned.
I need it to support a CI/CD process for two separate services that use the same repo, but each one of should be deployed with a different configuration. I want the repo alias to prevent adding conditions to my code.
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.
We have 150+ repositories on our GitHub, for different clients. Now we hired new employee to take care of the managed services process and he requires access to all the repositories. Inviting him as a collaborator to all repositories one by one is going to take plenty of time.
Is there a way to add him to all repositories at once? A command or some trick in GitHub that I do not know.
If those GitHub repositories were all part of the same organisation, that would be easy: see "Inviting users to join your organization"
If not, you can script that with the GitHub API:
list all your repositories
for eeach repo, add your collaborator to it.
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.