4

In our Git repository we have about ten very important files. These files are referenced by lots of other files, so if they get moved stuff breaks. But because of how we have our dev environment setup, this breakage won't be detected immediately, so what happens is: 1) a developer moves an important file, 2) they push the commit, 3) a few days later our sys admin gets to clean up the mess.

To prevent this we'd very much like to find a way to limit our Git repo so that only certain users can alter these files. However, I've tried searching Stack Overflow, and so far the only solution I've found are pre-commit hooks (or tools which we can't use because we have GitHub and not our own Git installation).

Are pre-commit hooks (which are a pain to get everyone to use, and can easily be disabled) the only way to enforce something like this? Or is there any other way to limit changes to certain files by user in Git?

machineghost
  • 33,529
  • 30
  • 159
  • 234
  • Put them in a separate repo and use it as a submodule. – ScottMcGready Aug 31 '15 at 23:41
  • 3
    Ensure that the build procedure depends on these files (perhaps by simply adding some `make` target to check them). Then use git commit hooks. – Basile Starynkevitch Aug 31 '15 at 23:46
  • You'd have more options with something like github where you have a more gated access with pull requests and such. But on a basic level on the repo (the remote one your team pushes to), you could do actual file system level permissions like chmod -R a-w /path/to/repo.git The goal would be to make the file itself read only (for all or certain users). – Jason Hughes Aug 31 '15 at 23:51
  • Have a rule not to commit to (say) master except via pull requests. Then code review, test run has to pass etc (perhaps including automated checks of this kind of thing) before merging to master. – Croad Langshan Aug 31 '15 at 23:53
  • If you use gitlab you could enforce permissions, like [this](https://about.gitlab.com/2014/11/26/keeping-your-code-protected) – Jason Hughes Sep 01 '15 at 00:09

2 Answers2

5

How big is your dev team? It sounds to me like the simplest solution is:

  1. Clear communication to the dev team not to change these files.
  2. As @Basile Starynkevitch mentioned, a build-time check to catch changes quickly
  3. If desired, a git pre-commit hook. Yes, it's easy to get around, but to do so they have to explicitly go against what was communicated to them.
  4. When someone forgets and changes the files, reminding without shaming the team.

Alternate Solution
Put the files in a separate git repository and give most of the team only read-only access.

xdhmoore
  • 8,935
  • 11
  • 47
  • 90
2

There is no per-file permission in Github. Some other systems such as gitolite seems to support it though.

You could probably cook a custom solution by using a custom hook and to revert automatically offending commits but I don't recommend it.

Ensuring that the developers don't break the repository is the role of a buildfarm / continuous integration (see Travis), not Git.

The best solution here would be to setup a test suite checking for this kind of thing and making sure that the developer are both running it before sending a pull request for review and the your CI system is also running it to make sure you're not merging anything non functional. With that, you are pretty much insured not to encounter this issue anymore.

Community
  • 1
  • 1
Thomas Moulard
  • 5,151
  • 2
  • 21
  • 28