Git, the version control system originally written by Linus Torvalds, is one of the most widely used Linux commands. Like other popular commands, such as apt or vim, an entire ecosystem of tools has grown up around it. In fact, Debian’s stable repository alone lists over 60 secondary tools whose names start with “git” and around 70 with unique names.

These tools cover a vast range of functions. Some, like git-github and git-gitlab, help you more efficiently use other services. Others enable particular text editors: git-el enables Emacs support, while git-email adds functionality. Still others are commands to run reports on authors, commits, and other activities; to generate packages and send them to the repositories of distributions from within Git; to clean up repositories; and much more. There is even Gitless, an experiment to create a version control system on top of Git. Most of these tools are standalone scripts, but a minority are add-ons to Git and run as an option to the basic git command. Look beyond the Debian repositories, and you are likely to find as many choices again.

Some users install git-all and sort through all the secondary tools at their leisure. But what if you are more selective about what you put on your hard drive? Below are seven general utilities that can benefit most Git users.

git-big-picture

The command line is text-oriented, but some users benefit from a visual aid. For these users, git-big-picture provides a visualization tool that is the equivalent to git branch. It displays branches in numerical and then alphabetical order. For other users, the command provides a memory aid, perhaps as a map to monitor large numbers of branches. The command structure is:

git-big-picture --format=FORMAT --outfile=FILE --viewer=VIEWER GIT-REPOSITORY

The formats supported are SVG, PNG, PS, and PDF (Figure 1). By specifying a viewer, you open the result right after the command is processed.

Figure 1: git-big-picture provides a map of the current repository that can be kept open in a separate window.

git-cola

While Git is designed to work from the command line, sometimes you need a graphical interface for an overview. Of all the half dozen or so graphical interfaces for Git, git-cola is by far the most efficient; its developer describes git-cola as a “caffeinated” version of Git.

The git-cola GUI consists of three main windows (Figure 2). The first window is a file manager that lets you choose a Git repository. The second is the main working window, with Status, Commit, Branches, and Diff panes and accompanying menus. This window is likely to be immediately comprehensible to anyone with a basic understanding of Git. The third shows a detailed view of the current branch and its contents, as well as a map of all the repository’s branches. Like the second window, the third has a simple top-level structure, but some of its dialogs demand more expertise and can be formidable in their detail.

Figure 2: git-cola offers an easy-to-navigate graphical interface.

git-crecord

Based on a similar tool for the Mercurial version management system, git-crecord can commit files in batches and set up comparisons in Git. In addition, its graphical interface and color-coding provides an overview of the repository. For example, in Figure 3, three files are staged, but not yet committed. Using git-record, users can choose to commit all three files or only one or two.

Be aware that git-crecord integrates with the git-core, so that its command structure is git crecord. It has no options and therefore no man page.

Figure 3: git-crecord provides a basic interface for batch operations.

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.

git-extras

For staging and committing files as well as using with diff, git-extras provides a basic graphical interface.

As if 60 utilities in the repositories were not enough, git-extras collect over 80 scripts for Git. While git-extras has its own man page, each script also has a man page. Like the packages in the repository, git-extras covers a wide variety of purposes. Some of these scripts duplicate functions that are already in Git, but with different, improved options. Many make housekeeping tasks for branches easier. Five of the most useful are:

• git-back: Removes the latest commits. The bare command removes the last commit; if followed by a number, it removes that many of the latest commits.
• git-bulk: Runs standard git commands on multiple repositories at the same time. The command could, of course, cause unintentional damage if used carelessly. For this reason, it should be used with the -g option, which asks for approval before making any change.
• git-sed: Searches the files in a repo for a string and replaces it with a string.
• git-merge-repo: Merges two repos.
• git-obliterate: Rewrites commits, changing both contents and histories.

There is not enough space to mention all the goodies in git-extras. Install it and explore for yourself -- it’s a must-have for almost everyone.

Finding More Commands

If git-extras is not enough, there is no shortage of other enhancements, especially if you delve into specialty areas. GitHub alone returns 79 results in a search for “git add-ons.” An especially noteworthy repository is Steve Mao’s Awesome Git Add-Ons, which links to demonstrations of dozens of tools. These sources alone can take hours to explore.

Of course, remembering the optimal size for repositories that is the reason for git-sizer, you will likely want to be cautious about commands that add their command files to a repository itself. After all, the last thing you want is to fill the repository directory with tools rather than your development files. However, if you are willing to take the time, you can soon have your Git repositories running exactly as you want.