git-crypt

This tool provides encryption to be used with a Git repository. It can be used to decide which files should be encrypted and which users can encrypt or decrypt. To set up an encrypted Git repository, use gpg --gen-key to create a key for each user.

Next, to make files visible locally, but not on a pull request (i.e., remotely), run git-crypt init to initialize the repository for use. Then select the files that will be affected by creating a .gitattributes file to place in the repo. For each file to encrypt, use the format:

FILE filter=git-crypt diff=git-crypt

Wildcards can be used to reduce the number of entries. According to some users, you can ensure that .fileattributes is not encrypted by adding the line:

.gitattributes filter !diff`

However, my system reads the line as an error.

The only ways remote users can read the encrypted files is if their encryption key is added using the command

git-crypt add-gpg-user  GPG_USER_ID

or if the repository key is exported with:

$ git-crypt export-key KEY-PATH

After which, the remote user can access the files with:

git-crypt unlock KEY PATH

You can also temporarily make the files accessible to everyone by using git-crypt unlock. To re-encrypt, use the lock option.

git-repair

The core of Git includes a fsck command. However, while fsck finds problems in a repository, it does not fix them. By contrast, git-repair runs fsck and makes what repairs it can. First, git-repair deletes corrupt objects and retrieves remote versions of missing objects. After that, if the repository is still corrupt, using the --force option, git-repair can revert branches to an uncorrupt state, delete lost branches, and remove missing files from the index. Note that git-repair's purpose is to create a functional repository, not to recover everything. Consequently, you may need to recover some files from cloned repositories or backups. After running git-repair, you should run git fsck and git gc to finish the restoration (Figure 4).

Figure 4: git-repair works to restore a corrupted repository.

git-sizer

Git repositories are intended for source text. For that reason, they work best when smaller than one gigabyte and can become unwieldy at about five gigabytes. Although it might be convenient to store all Git-related material in the same directory, it is more efficient to have another directory for media files, logs, and files generated by other commands. Periodically, too, you might check for unnecessary branches. This housekeeping is simplified by git-sizer, a simple command without any options, that reports on the contents of a repository and flags any potential problems. As a side effect, git-sizer also provides an overall view of a repository's contents (Figure 5).

Figure 5: git-sizer gives information to help you control the size of a repository.