# git-extras: a pack of git subcommands that installs once and stays out of the way

> tj/git-extras is a shell script collection that adds git subcommands like git summary, git effort and git changelog, installed with a single make. The 6.4 release renamed the assumed default branch from master to main, which is the one upgrade step that needs your attention.

**tj/git-extras** — GIT utilities -- repo summary, repl, changelog population, author commit percentages and more

- Repository: https://github.com/tj/git-extras
- Stars: 18,120 · Forks: 1,228
- Language: Shell
- License: MIT
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/tj-git-extras

## A naming convention instead of a framework

git-extras takes the simplest possible approach to extending git. There is no daemon, no plugin registry and no configuration file format to learn. Each utility is a shell script in `bin/` named `git-` followed by the subcommand, and git finds it on your `PATH` the same way it finds `git commit`. That is why the Makefile can build the command list with a single wildcard over `bin/git-*` rather than maintaining a manifest.

The collection is described as GIT utilities covering repo summary, a repl, changelog population and author commit percentages. The description reads like a feature list because the set is genuinely broad, and the command count is in the high tens across categories like release, branch and archive work. The README points readers at `Commands.md` for basic usage and at an `Installation.md` page for setup, and the tree also carries a `man/` directory where each command has its own manual page written in markdown and converted by `make docs`.

Everything is MIT licensed and the repository's primary language is Shell. For a collection of scripts, that combination means you can read a command before running it and adapt it when it does not fit your workflow.

## What make install actually does

The default target is `install`, so a bare make is the whole installation story. The target depends on `check`, which runs `check_dependencies.sh` first and prints a report, which is the reason to run it before anything else if you want to know what is missing.

The path variables at the top of the Makefile are worth reading, because they explain the per-OS branching:

```make
PREFIX ?= /usr/local
BINPREFIX ?= "$(PREFIX)/bin"
SYSCONFDIR ?= $(PREFIX)/etc
```

`PREFIX` defaults to `/usr/local` and is overridable, so a system-wide install without root is a matter of pointing `PREFIX` somewhere writable. What gets installed goes beyond the scripts themselves. Manual pages are placed under a `MANPREFIX` that differs for FreeBSD, where `/usr/local/share/man/man1` does not apply, and shell completions land in `bash_completion.d` on macOS and FreeBSD but in `bash-completion/completions` elsewhere.

There is also a Homebrew path. When `INSTALL_VIA` is set to `brew`, the install target applies `brew-release.patch` with `git apply` before copying files, and aborts with a message if that patch does not apply cleanly. The scripts are copied with mode 775, which is called out in a comment as a deliberate change from the restrictive mode `mktemp` gives a file by default.

## Why release 6.4 changed how your commands behave

This is the single most important upgrade note in the project, and it is buried in a README section with an unremarkable title. As of git-extras 6.4, the assumed default branch name changed from `master` to `main`. Git itself moved that way, but a script that hardcoded `master` would silently compare against a branch that does not exist in your repositories, which produces empty output rather than an error.

The README names the commands affected: `git archive-file`, `git delete-merged-branches`, `git delta`, `git pull-request`, `git show-merged-branches`, `git show-unmerged-branches` and `git squash`. Every one of them compares branches, so every one of them is affected by the name.

If your repositories still use `master`, you have two settings to choose from. Change either `init.defaultBranch` or `git-extras.default-branch` to `master`, and the README is explicit that the latter takes precedence when both are set:

```bash
make
git config git-extras.default-branch master
```

Setting it explicitly in each repository, or globally with `git config --global`, is worth doing rather than relying on which branch a given clone happens to have checked out.

## What the recent releases say about maintenance

The project is not archived and the last push was on 2026-09-21. Version 7.5.0, named Labradorite, was published on 2026-05-10, coming after 7.4.0 Kyanite in June 2025 and 7.3.0 Joanneumite in October 2024. That cadence, a major or minor release roughly every nine months, is what you would expect from a collection maintained by one person alongside other work.

The release notes read like a maintenance log rather than a feature announcement, which is a useful signal about where the effort goes. 7.5.0 includes a fix to make `git-whatchanged` use `git-log`, improvements to the bash completion contributed by someone else, a typo fix in the `git rename-branch` man page, and a set of dependency bumps for GitHub Actions by dependabot. One entry is a genuine safety improvement: Git Magic's use of `-f` was changed to `--force-with-lease`, so a forced update refuses to clobber work someone else has pushed.

Earlier releases show features arriving as contributions: 7.4.0 added support for the `GITHUB_TOKEN` environment variable in `git-fork` and `git-pull-request` and introduced a `git-continue` command, while 7.3.0 added `git-rename-file`, fixed the commit count in `git-summary` and added pathspec support to `git-missing`. A script collection that accepts this kind of patch is easier to extend than one maintained in isolation.

## Where the documentation lives, and what it leaves out

The README is deliberately thin. It links to screencasts for an introduction covering `git-ignore`, `git-setup`, `git-changelog`, `git-release` and `git-effort`, points at `Commands.md` and `Installation.md`, and explains the default branch change. There is no feature matrix, no comparison table and no configuration reference in the README itself.

The real documentation is in the repository. `Commands.md` carries basic usage and examples, `Installation.md` covers setup, `History.md` is the changelog the release notes point at, and each script has a man page under `man/` with the command name in the filename. Running `make docs` generates the HTML and man page versions from those markdown files, so the man pages are generated artifacts rather than a separate hand-maintained copy.

Development infrastructure is visible too. There is a `tests/` directory alongside a `.pytest.ini`, which suggests the test suite is driven by pytest and likely exercises the shell scripts as external commands, and `check_integrity.sh` for validating the collection. A `vendor/` directory and a `.gitmodules` file indicate that some test dependencies come from submodules. The tree also includes `install.cmd` for Windows, `need_git_commit` and `not_need_git_repo`, which are git hooks shipped alongside the commands.

Knowing the README defers to the repository is the practical takeaway: budget a few minutes reading `Commands.md` rather than expecting the front page to tell you which of these commands you need.

## How it compares to the other git tooling people install

The searches people run around this project cluster into a few different categories, and it helps to separate them, because they solve different problems and can be used together.

git-extras is read-only reporting plus branch housekeeping in shell. It maintains no state outside your repository, keeps no index of its own and does not run as a service. `git summary` and `git effort` in particular are views over history you already have, which is the cheapest kind of tool to try and the easiest to abandon.

Git Town takes a different slice: it manages the branch workflow itself, with commands for creating, syncing and shipping branches rather than for describing history. If your problem is that feature branches accumulate and merges are tedious, that is the gap it fills. Git-annex solves a different problem again, using git to track large binary files that belong in a repository but not in its history, and it brings its own key-value store for file contents.

Tools like Git Open and commitizen target narrower workflows, one for opening a pull request from the command line and one for generating conventional commit messages. The overlap with git-extras is partial in each case, and installing several at once is normal. The reason to be careful is that several projects want a `git-something` name, so check for collisions between what you already have on `PATH` and what the install is about to copy into `/usr/local/bin`.

## Conclusion

git-extras is a good fit for a developer who wants repo history summaries and branch housekeeping without learning a tool that maintains its own state. Every command is a script in `bin/` named `git-something`, which makes the whole collection readable and easy to adopt one command at a time. Two things to check before you install: whether the `make` write to `/usr/local/bin` works for your user, and whether your repositories use `main` or `master`, since 6.4 switched the default to `main` and seven commands read it. Run `make check` first to see the dependency report, then set `git-extras.default-branch` explicitly if your convention is `master`.

## FAQ

### How do I install git-extras on my machine?

Clone the repository and run `make` from its root, since the default Makefile target is `install`. It depends on a `check` target that runs `check_dependencies.sh`, and the prefix defaults to `/usr/local` but can be overridden with the `PREFIX` variable.

### Why do some git-extras commands show empty output after installing?

As of version 6.4 the assumed default branch name changed from `master` to `main`, which affects `git archive-file`, `git delete-merged-branches`, `git delta`, `git pull-request`, `git show-merged-branches`, `git show-unmerged-branches` and `git squash`. If your branches are still `master`, set `git-extras.default-branch` or `init.defaultBranch` to `master`.

### Does installing git-extras change how my existing git repository works?

The commands are separate scripts named `git-something` and placed on your PATH, so they only run when you type them. Nothing in the collection replaces git builtins, and the install also writes manual pages and bash completion files alongside the scripts.

### What license is git-extras released under?

The repository is MIT licensed, which matters if you want to copy a command out of `bin/` and adjust it for your own workflow. The project also accepts contributions by pull request and keeps a changelog in `History.md`.

## Sources

- [Issues](https://github.com/tj/git-extras/issues)
- [License: MIT](https://github.com/tj/git-extras/blob/main/LICENSE)
- [README](https://github.com/tj/git-extras/blob/main/README.md)
- [Releases](https://github.com/tj/git-extras/releases)
- [tj/git-extras on GitHub](https://github.com/tj/git-extras)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tj-git-extras