git-extra-commands: a ZSH plugin of borrowed git helper scripts, with attribution built in

A collection, and the README's honesty about what that means

The project description is blunt: a collection of git utilities, useful extra git scripts, tutorials and other useful articles. The README makes the same point in its own words, saying the project is a ZSH plugin that packages some extra git helper scripts the author has found, and that the collection and the scripts written in it are licensed with Apache 2.

Two details in that paragraph decide how you should treat the repository. The first is that some scripts came from other sources and may have different licensing, with their licence information included inline in the script source. The second is the removal policy: if you wrote one of the scripts and want it removed, the author asks you to make a PR or file an issue and says it will be removed.

That removal commitment is unusual and worth holding in mind. A collection of borrowed scripts carries a licensing exposure that the author has chosen to manage by taking them out when asked, rather than by rewriting them.

The scripts are named with a git- prefix, which is the convention that lets git find them as subcommands. The table in the README lists them with an original source column and a description, and the sources range from blog posts and wiki pages to other people's dotfiles and Stack Overflow answers. Three entries are credited directly to the repository author, git-branch-date, git-branch-diff and git-branch-name, all listed as Joe Block with a [email protected] address.

A few examples show the range. git-amend-all adds all modified and deleted files, but not new files, to the previous commit by amending it. git-attic lists deleted files in a form designed to be copy and pasted, since the second field can be passed to git show to display the file contents. git-add-match uses expect to stage hunks matching a search term. git-change-author rewrites one author or email in the history to another, and git-changelog transforms git log output into a complete Changelog for projects that have not been maintaining one.

The scripts that change history, and the ones that warn you

The collection splits cleanly into scripts that read and scripts that write, and the write side is where a reader needs to be careful.

git-branch-rebaser is the clearest warning in the table. It kicks off an interactive rebase of all the commits on your branch, and the README marks it with an italic caution that it includes pushed commits, so be careful. That is a script that rewrites history you have already shared, and the README is upfront that the scope includes commits other people already have.

git-change-author and git-changelog fall on the same side of the line, since the first rewrites authorship in the history and the second rewrites log output into a different format. git-amend-all mutates the previous commit. By contrast, git-branch-diff only diffs your current HEAD with the default branch of the origin remote, and git-authors and git-changes simply list authors in descending commit-count order, with git-changes described as a symlink to git-authors.

Two entries are explicitly described as opinions rather than as neutral utilities. git-branch-clean performs branch clean, which the table describes as removing various copies of a branch, for example foo-wip and origin/foo, and it is credited to the Hefeweizen account. git-branches-that-touch shows which branches touch files under a path that are remote, unmerged, have a commit in the last six months and whose name does not start with enterprise-.

That last one is a good example of the collection's character. A filter that excludes branches whose name starts with enterprise- is a personal convention, not a general rule, and it is fine in a dotfiles collection as long as you read the table before assuming a script does what its name suggests.

Installation routes through ZSH plugin managers and manual setup

The README lists four ways in, which is a sensible set of choices for a shell plugin. The first three go through external tools: Zgenom, Antigen, and oh-my-zsh. The fourth is a manual Bash installation for people not using a ZSH framework.

The plugin's own entry point is the git-extra-commands.plugin.zsh file in the repository root, which is the name a ZSH plugin manager expects, and the repository also ships bin/ and completions/ directories alongside it.

git-extra-commands.plugin.zsh
bin/
completions/

The plugin file is what makes the git- prefix work. Once the plugin is loaded, git can find each script as a subcommand, so git branch-date and git authors become available the way git log is.

The README is careful about the ZSH framing, noting that the collection does not actually require ZSH but that packaging it as a ZSH plugin makes it more convenient for people using a ZSH framework to use the collection. That distinction is real. The scripts are shell utilities that call git, and the ZSH packaging is about discovery and loading, not about a ZSH specific implementation.

The topic tags on the repository reflect that audience: bash, zsh-plugin, zsh-plugins, oh-my-zsh-plugin, prezto, antigen and zgenom all appear, alongside devops, sre, devops-tools and git. A plugin manager user on any of those frameworks has a supported path.

Beyond the scripts: tips, articles and external utilities

The repository is not only a script collection. The README has a section on other useful git stuff with two subsections, one for articles, blog posts and books and one for external git utilities, and then a section of miscellaneous tips.

Three of those tips are named in the table of contents, and they are the kind of configuration that saves a recurring annoyance. There is one on making it easier to check out the default branch, one on having git cope with typos, and one on rewriting git:// with https://, with a sub-item suggesting replacing it with ssh instead.

That default branch tip connects to a script in the table. git-checkout-default-branch is credited in the source column with the personal note that the author got tired of keeping track of which repositories use main, master or something else as default branch, and it checks out the default branch of the origin remote. The git-branch-diff script, also by the same author, is described in the same terms, diffing the current HEAD with the default branch of the origin remote.

So there is a small cluster of scripts here aimed at a specific, common problem: repositories whose default branch name varies, and the habit of comparing your work against it. Whether that is useful to you depends entirely on your workflow.

Project hygiene, release cadence and licence obligations

The repository carries the usual scaffolding for a project that expects contributions: a CODE_OF_CONDUCT.md and a separate CodeOfConduct.md, a Contributing.md, a .pre-commit-config.yaml, a .codeclimate.yml and a .circleci directory. The continuous integration badges are for Awesomebot and Megalinter, and there is a build status badge, so the shell scripts are checked by automated linters rather than by review alone.

The release tags are v2025.11.6 from 2025-11-06 and v2024.11.19 from 2024-11-19, both date based, and the last push to the main branch was on 2026-10-15. The repository is not archived. So the project is still being touched, while the tagged releases are sparse, which is consistent with a collection whose scripts mostly do not change.

The licence situation needs a clear head. The repository itself is Apache-2.0, which is permissive and fine for internal use and modification with attribution. But the README's statement that some scripts came from other sources and may have different licensing, with licence information included inline in the script source, means the effective terms of any individual script depend on its own header. The apache-2.0 badge at the top of the README describes the collection, not necessarily every file in it.

One more thing about the dependency file. The requirements.txt at the root is not a runtime dependency list for the shell scripts. It is a large Python pinning file that includes ansible, boto3, GitPython, PyGithub, moto, black, mypy-extensions, pipreqs, docker and similar tooling, which reads as the environment used for the repository's own automation and the Awesomebot workflow rather than something a user of the plugin needs to install. Nothing in the README tells you to install it, so treat it as internal.

Editorial conclusion

Adopt git-extra-commands if you work in ZSH with oh-my-zsh or a similar framework and want one place to pick up the git scripts you would otherwise paste from a dozen dotfiles. Do not treat it as a maintained tool, because the README states it is a collection of scripts gathered from other sources with possibly different licences, and the last release was v2025.11.6 while the last push was on 2026-10-15. Verify the licence of any single script you plan to copy into a commercial codebase, since the README says licence information for borrowed scripts is included inline in the script source rather than in one place.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. unixorn/git-extra-commands on GitHub