(Official Git Repo)[https://github.com/AGWA/git-crypt]
After a couple of experiments and repo resets, I've learned that if a file has ever been committed to the repository in an unencrypted state, unfiltered by git-crypt, then it will never be filtered by git-crypt. It is designed to only work on new files being filtered before their initial commit. This makes sense, because otherwise you would have a false sense of security by encrypting files at a point in time that had previously been committed insecurely.
A .gitattributes file is used to tell git to filter blob pattern filename matches through git-crypt. This only works if git-crypt init has already been performed. The order of operations is critical in this sequence, otherwise the files with secrets will be exposed.
- install git-crypt on your local system (Ubuntu has a package, Macs can brew install)
- perform
git-crypt initin the root of the repo on your local system - create a .gitattributes file with lines for
<blob_pattern> filter=git-crypt diff=git-crypt - add the secret files matching the blob pattern
- make sure the secret files are not tracked by the
.gitignorefile - add
crypt.keyto the.gitignorefile - export the encryption key with
git-crypt export crypt.key - review what needs to be committed
- commit and push up
- share the
crypt.keyfile securely with collaborators - they must also install git-crypt and perform
git-crypt unlock crypt.keyfrom the root of the repo (only once)
- It is critical that you do NOT accidentally encrypt the
.gitattributesfile. - Files committed before git-crypt init and .gitattributes will NEVER be encrypted.
- There are many additional options for encryption and unlocking, the
crypt.keypattern in this repo is just one example.
Once git-crypt is initialized and in use, there is nothing special needed. The encryption and decryption happen automatically and transparently according to the .gitattributes rules. The init, export, and unlock are each only performed once, and never again. Everyone uses git normally.