CODEWITHSUNDEEP
gitgithub
machineghost
machineghost

Reputation: 35725

Git: Any Way I Can Prevent *Most* Users From Editing Files?

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?

Upvotes: 5

Views: 7089

Answers (2)

xdhmoore
xdhmoore

Reputation: 9915

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.

Upvotes: 5

Thomas Moulard
Thomas Moulard

Reputation: 5542

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.

Upvotes: 2

Related Questions