git-friendly trades verbose Git flags for five short commands

Five separate executables sitting on your PATH

The repository root holds a script per command: branch, merge, pull, push and stash, plus install.sh and a Formula directory for Homebrew packaging. There is no plugin, no hook and no Git alias file. Once the directory is on PATH, those five words become commands in their own right, and they are not Git subcommands, so `git pull` still behaves exactly as your Git version always has.

The scripts are thin wrappers, and that thinness is the whole design. Each one knows a small set of flags that suit most day to day work and applies them without being asked. The stated requirements give the picture: Git 2.27 or newer, because branch and merge use git switch, and pull uses --autostash. Bash 3.2 is enough, which is the version macOS ships, and no bash 4 features are used. The GitHub CLI is optional and only used to detect a pull request URL during push. Package managers and clipboard helpers are optional too, and are used only when the machine actually has them.

The practical effect is a shell where the same words mean something slightly different from what Git means by them, which is convenient until two tools with the same name are on PATH at once.

pull stashes, rebases, updates submodules and installs dependencies

Pull is the command that carries the most machinery. In order, it stashes any local changes, pulls from the remote using rebase, updates submodules, pops your stash, and finally runs a dependency install when a manifest changed. The install step picks between bundle install, npm install, yarn install, pnpm install, uv sync and composer install, triggered by changes to files such as Gemfile, package.json or uv.lock.

That ordering matters more than it looks. The stash and pop are there so the rebase can run over a dirty tree, and the autostash behaviour that makes it possible is one of the reasons the project asks for Git 2.27. A failed rebase therefore leaves both the Git operation and the dependency step in a state you have to reason about rather than a single error message.

Here is the sequence the project documents, with the comment lines exactly as given:

pull
branch awesomeness # Create a new branch (or switch to existing one)
echo "BUMP" >> README
git commit -a -m "Righteous bump"
branch main        # Switch back to main
merge awesomeness  # Merge awesomeness branch to main
push               # Push changes

Notice that the same session still needs raw git commit. The wrappers cover branch, merge, pull, push and stash. Everything else, including adding files to the index, stays on stock Git, so you are running two mental models side by side.

push copies a compare URL to the clipboard after the push lands

Push does two things. It pushes your changes to the remote, and it copies a compare URL, the kind of link that shows the difference between two revisions, to your clipboard. The documented example points at the project's own history, for instance a compare link of the form https://github.com/git-friendly/git-friendly/compare/e96033...5daed4. The link is useful in review threads and pull request bodies, since a reviewer can see exactly what moved between commits.

Two dependencies sit behind that clipboard step. A clipboard tool has to exist, so pbcopy on macOS or xclip on Linux, and the project states plainly that the copy works on Mac and Linux. When the GitHub CLI is installed, push also detects a pull request URL, which is why gh is listed as an optional requirement rather than a hard one. Without either, the push still works and you simply lose the shortcut.

Extra arguments are passed straight through to git push, so force pushes are available without leaving the wrapper:

branch [name]
branch -d [name]
branch -D [name]
branch -

Those are the branch forms, and the last one returns you to the previous branch. Passing through means the wrapper will not save you from a mistyped flag, and a wrapper that accepts -f is also a wrapper that will not ask whether you meant it.

branch sets up remote tracking, merge rebases local-only work first

Branch creates a local branch if it does not exist and switches to it if it does. The part worth knowing is the tracking setup: when a matching remote branch exists, the script arranges for it to be tracked, so a plain pull works instead of typing the origin and branch name every time. With no argument at all, it lists local and remote branches. Deletion uses the -d and -D keys, which mirror what Git itself accepts, and the single dash switches back to the previous branch.

Merge takes a branch name and merges it into the current one, with one added rule: if the branch is local-only, it rebases first. Rebasing a local branch before merging rewrites its commits onto the current branch tip, so the result is a fast linear history rather than a merge commit. The trade-off is that a rebase during a merge can surface conflicts at a moment when you expected a straightforward merge, and the error will point at the rebase rather than at the merge.

The stash script completes the set. Run without arguments it stashes untracked files as well as tracked ones, which is a deliberate difference from plain git stash. With arguments it behaves like the standard command:

stash
stash pop

The untracked-by-default choice is the one that will surprise you first if you rely on the plain behaviour, because new files disappear from your working tree along with the modified ones.

Installing through Homebrew, Copr, a curl script, or a checkout

The Homebrew route is the shortest. The formula lives in the repository and publishes to a tap, and releases update the URL and checksum in both places:

brew install git-friendly/git-friendly/git-friendly

For Fedora, the project points at an unofficial Copr build of stable releases rather than shipping its own package:

dnf copr enable fuhrmann/git-friendly
dnf install git-friendly

The third option is a one line installer that downloads the scripts into /usr/local/bin, and the project notes that without write access to that directory you would need to run it with sudo. The same script accepts a target directory, which is the sensible route on a managed machine where /usr/local/bin is not yours:

curl -sS https://raw.githubusercontent.com/git-friendly/git-friendly/main/install.sh | bash

Finally there is the source path, a clone plus a PATH entry:

git clone git://github.com/git-friendly/git-friendly.git ~/dev/git-friendly
export PATH=~/dev/git-friendly:$PATH

The PATH line goes into ~/.bash_profile or ~/.bashrc so it survives new terminal sessions. A curl one liner piped into bash is a real trade-off worth naming: you are executing a script from a branch called main, and the revision you run is whatever that branch points at when you run it, not a tagged release.

Every behaviour is switchable through GIT_FRIENDLY_ environment variables

The configuration surface is a set of environment variables, each naming a behaviour to disable, and each read by a specific command. The example given in the documentation disables the bundle install step inside pull by exporting GIT_FRIENDLY_NO_BUNDLE, with the value true. The rule is that any value except 0 or false switches the option on, which means a typo such as GIT_FRIENDLY_NO_BUNDLE=0 in a profile silently re-enables the step you meant to turn off.

The full set covers the package manager runs, one variable each: GIT_FRIENDLY_NO_BUNDLE, GIT_FRIENDLY_NO_COMPOSER, GIT_FRIENDLY_NO_NPM, GIT_FRIENDLY_NO_YARN, GIT_FRIENDLY_NO_PNPM, GIT_FRIENDLY_NO_BUN and GIT_FRIENDLY_NO_UV. Two more cover Git behaviour rather than dependencies: GIT_FRIENDLY_NO_REBASE_ON_PULL turns off rebasing local commits on top of the updated remote branch, and GIT_FRIENDLY_NO_COPY_URL_AFTER_PUSH turns off the clipboard copy.

This is where the real risk of the tool lives. A wrapper that changes semantics is fine when you know it, and awkward when behaviour depends on variables set in a shell profile that a teammate does not have. The two Git level variables are the ones to agree on across a team, since a rebase on pull is a history difference, not a convenience difference.

The trade-off: convenience over predictability, and names that could collide

Every default here is a guess made on your behalf, and the guesses are the point. Pull rebases, merge rebases a local branch first, stash takes untracked files, push copies a URL. Each of those is a reasonable choice and none of them is the choice a cautious reader of the Git manual would make every time. A wrapper that hides flags also hides the ability to see what is about to happen, and a CI job that runs git pull will behave differently from the same line you run in your shell.

The second limitation is the naming. branch, merge, pull, push and stash are ordinary words, and the installation puts them on PATH for every project. Any other program on your system using one of those names will either lose an argument to the wrapper or lose the name to it, depending on PATH order. The documentation does not address collision resolution, and it does not offer a namespaced invocation, so the mitigation is manual: check what your shell profile and your Ruby, Node or Python tooling already define before the install script runs.

The third is that the dependency step in pull is a heuristic, not a manifest reader. The documentation lists Gemfile, package.json and uv.lock as examples of files whose changes trigger an install, but it does not describe exactly how the check is made, so in a monorepo with several manifests you can end up installing more than you expected.

The alternative is your own gitconfig aliases

The same repository points at the plain alternative: editing your global ~/.gitconfig, adding ANSI colour, command aliases such as git st in place of git status, and automatic remote tracking. The comparison is instructive because the two approaches sit at different levels. A gitconfig alias is a name you choose and a command you write, so it is explicit, reviewable in a dotfiles repository, and visible to anyone reading your config.

git-friendly instead ships fixed implementations of five specific operations. It can do things an alias cannot express in one line, such as running the matching package manager after a pull, or copying a compare URL after a push. What you give up is the ability to read the exact command before it runs, since the logic lives in scripts rather than in a line of config you can inspect.

The practical split is by team. Aliases suit people who want a familiar name for a command they already understand. git-friendly suits people who want a fixed sequence of steps, particularly the rebase plus stash plus submodule update plus install sequence that makes up a normal pull in a managed Ruby or JavaScript project. What the repository offers on top of either is a bash completion block that routes the first argument of the branch command to the Git completion for branch or checkout, plus the option of adding the current branch to your shell prompt so you can see where you are.

Editorial conclusion

Adopt git-friendly if you work in Ruby, JavaScript or Python repositories daily and want one command to rebase, update submodules and refresh dependencies. Skip it if your team depends on precise, explicit Git invocations, on CI parity between your laptop and your server, or if the bare names pull, branch, merge, push and stash are likely to collide with other programs in your PATH. Before installing, check what your own shell profile already defines, and confirm that the automatic package manager step during pull matches what your project actually expects.

Frequently asked questions

Official sources

1. git-friendly/git-friendly on GitHub
2. Issues
3. License: MIT
4. README
5. Releases