How can I mark a committed file as read-only in Git?
I have a file that is being checked against Git. The file should contain the API key, but I don't want to pass the API key to Git for security reasons. Instead of an API key, I'll explain how to create an API key for each developer.
I don't want any developer to accidentally pass their API key and overwrite the main file.
I have:
- Added a file to the file
.gitignore
, but since it's already committed, it doesn't do anything. - Run the command
git update-index --assume-unchanged myFile.js
- Added a command to the explain file to inform other developers that they should run this command as well.
However, I just went to my laptop, forgot to run the command, and accidentally passed the key to the repo. I am looking for a more fail-safe method. Basically, I want to push the original version of a file to GitHub and then disallow modifications to that file.
Is it possible?
For reference, the file looks something like this:
define(function () {
// The Simple API Access API key is used here.
// Please note that I've specifically omitted this key from GitHub for security.
// Feel free to generate your own in order to use YouTube API: https://code.google.com/apis/console/
// A valid key will look something like:
// Key for browser apps (with referers)
// API key: -------------------------------
// Referers: Any referer allowed
// Activated on: Apr 6, 2014 2:46 PM
// Activated by: ------------ – you
// NOTE: Please do not commit changes to this file once downloaded. CommandS:
// - Disable tracking: "git update-index --assume-unchanged src/js/background/key/youTubeAPI.js"
// - Enable tracking: "git update-index --no-assume-unchanged src/js/background/key/youTubeAPI.js"
var key = 'API_KEY_MISSING';
if (key === 'API_KEY_MISSING') {
console.error('YouTube API key is not present.');
}
return key;
});
source to share
One possible approach would be to set up some server side (for example update
) which
- check in clicked links that the hash from the blob in the question remains the same, and
- reject any click that contains links that change the hash of the blob in question.
Of course, such a hook on the server side will not prevent contributors from creating commits (locally, on their machines) that contain a different version of the file. However, after seeing some of their thrusts rejected, they will surely learn the lesson.:p
source to share
The answer to the question about the intended topic ("can I make git check a particular file as read-only") is "no, at least not directly" because git only stores one bit of file permission: executable or non-executable. All other bits are set the same for every file.
However, there are several tricks with hooks. As some commenters have suggested, you can test something on a hook on the server side to prevent pushing. You can use lubrication and clean the filters. You might have a hook post-checkout
that sets the file read-only.
The downside to all and all connections is that they have to be configured for each repository and users can override them (except for a server-side hook, assuming the user does not have direct access to the server). 1 This is also an advantage of the hook, although for naive users this is probably more of a disadvantage than an advantage, since git will not automatically set hooks by itself.
The hook post-checkout
is probably the most obvious place to set file permissions, since the git documentation includes this bit:
This hook can be used to ... customize metadata performance properties.
Conveniently, the hook is always triggered in the top-level directory, no matter where the user is, as long as the user is actually in the git working tree. 2 So, this is a very simple hook enough to change a single read-only file:
#! /bin/sh
# post-checkout hook to make one file read-only
chmod -w path/to/file
(on any system with chmod
anyway and don't forget to establish the connection as executable).
The user should put this hook in their repository at .git/hooks/post-checkout
(although you can commit the file itself to the repository and then copy or link it to the user, perhaps via a helper script).
1 So the server side hook is where you want to strictly enforce the policy (this is generally true).
2 That is, the following strikes the hook:
$ pwd
/home/user/dir/example
$ ls -l .git/hooks/post-checkout
-rwxr-xr-x 1 user group 27 Dec 18 11:10 .git/hooks/post-checkout
$ cd /tmp
$ GIT_DIR=/home/user/dir/example/.git git checkout master
Here, the current working directory is just that /tmp
, and there is no way for the hook to figure out what it should be (you can read $GIT_DIR
, but this is not necessarily helpful, since the directory required .git
should not be directly connected to the tree in the first place and that in installation is meant first of all GIT_DIR
).
Note that the presence of a work in a subdirectory in the tree does not cancel the hook; that what I mean by "seems to always run in the top-level directory".
source to share
If you don't want the developers to make certain changes to the repository, locking the repository and, instead, a Gerrit-like checkout system is a good solution. Individual changes are carried over to Gerrit and must be peer reviewed.
Any commit that adds a file that needs to be local, such as an API key file or a compiled object file, may be rejected.
The developer can then revise the commit, rewriting it to not include the offending file, resubmit for review. When it goes through the review, it gets selected to the appropriate target branch.
source to share
Another solution:
- Add your file to the repo by first renaming it (as template) eg.
myFile_template.js
- Ask the developers to copy the template to
myFile.js
and edit the details - Add
myFile.js
to.gitignore
Still not a very robust solution, as developers can still capture the information you are trying to hide, but at least the file won't show up in the list of states.
source to share