-1

Suppose I have multiple users working in a repository (azure devops) and there are multiple files & folders in it. There is one master branch for release and one dev branch for testing. Based on the dev branch, feature branches are created for coders. How can I only allow users with access (commit) to a specific file & restrict access to all others? Is it possible to apply this at a repo or branch level? Is there any way to achieve this?

I looked into Azure documentation, googled it. But I couldn't find a way to achieve this.

Athul Suresh
  • 1
  • You might try to pull it off with hooks. Controlling like this is alien to git because you _own_ your local repo. – eftshift0 Aug 02 '23 at 15:52
  • 2
    The best strategy is not to attempt restricting commits, but instead require PRs for all movement into important branches and apply access controls and processes to the PRs. There are ways to apply branch policies for PRs. – Paul Dempsey Aug 02 '23 at 17:13
  • 1
    See [Branch Policies](https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops&tabs=browser) in the Azure Devops documentation to start with. – Paul Dempsey Aug 02 '23 at 17:15

1 Answers1

1

If a user has read access to a repository, you should assume that they can access anything in that repository. From gitnamespaces(7):

The fetch and push protocols are not designed to prevent one side from stealing data from the other repository that was not intended to be shared. If you have private data that you need to protect from a malicious peer, your best option is to store it in another repository. This applies to both clients and servers. In particular, namespaces on a server are not effective for read access control; you should only grant read access to a namespace to clients that you would trust with read access to the entire repository.

All of that applies regardless of whether namespaces are used or not. Note also that anyone who can clone the repository can modify it arbitrarily on their own system.

If you're okay with those users having read access, but simply want to prevent them from modifying those files and then merging them into certain branches, there are a couple ways to go about that.

The first way, if you're using your own custom Git server, is a pre-receive hook, which can check to see if the data being pushed meets some criteria, and if so can accept it or reject it.

For most major forges, pre-receive hooks are not available, and you instead will want to force all changes to those branches to go through a pull request process. You can then require approval from a specific team for files being modified (GitHub calls this CODEOWNERS) or you can use a CI job to reject files from being modified based on whatever criteria you like. If that CI job is required to merge, users will not be able to bypass it, and you can implement an effective control.

bk2204
  • 64,793
  • 6
  • 84
  • 100