ghorg: cloning or backing up an entire organisation in one command

What one command replaces

The README opens by naming the pronunciation, gore-guh, similar to gorge, and then explains the joke: you use ghorg to gorge on orgs. The stated job is to quickly clone all of an org's or a user's repositories into a single directory, and the list of situations it says this is useful in is more revealing than the headline.

The five listed cases are searching an org's codebase with tools like ack, silver searcher or grep; bash scripting; creating backups; onboarding new team members by cloning all team repos; and performing audits. Read together, those say something specific about the tool. It is not a migration utility and not a CI system. It is a way to turn a remote organisation into a local directory that ordinary command line tools can work on, which is a much narrower and more useful job than most tools in this space attempt.

The scale fits the Go implementation. The repository is Apache 2.0 licensed, written in Go, carries 2,154 stars and 186 forks, and had 10 open issues at the last push on 2026-09-13. There is a `vendor/` directory in the tree, so the binary builds without network access, and the module requires Go 1.26.

Six providers behind one flag

The supported providers list is the first section of substance in the README, and it is more careful than most. GitHub is supported both self hosted and cloud. GitLab is the same. Bitbucket covers cloud and self hosted server. Gitea is self hosted only. Codeberg covers cloud and self hosted Forgejo instances. Sourcehut is explicitly marked as limited features.

Each provider has its own setup section and its own example file in `examples/`, which is the right amount of documentation for something where the token type and the base URL both differ. The README also handles the vocabulary problem honestly, noting that ghorg uses GitHub terminology for everything while GitLab and Bitbucket use different words, and pointing to a terminology chart. It warns that some features may differ per provider rather than pretending parity.

The module file shows what that support costs in dependencies. `github.com/google/go-github/v72` and `gitlab.com/gitlab-org/api/client-go` cover the two largest hosts, with `code.gitea.io/sdk/gitea`, `github.com/ktrysmt/go-bitbucket` and `github.com/bradleyfalzon/ghinstallation/v2` handling Gitea, Bitbucket and GitHub app authentication. Each provider gets a real SDK rather than hand-rolled HTTP, which is the reason the tool tracks API changes at all.

The default that will overwrite your changes

The README puts this in a blockquote before anything else, which is the right place for it, because it is the one thing that can lose someone's afternoon. With default configuration ghorg performs two actions: it clones a repo if it is not in the clone directory, and if the repo does exist locally it performs a git pull and a git clean on it.

Git clean is the word that matters. Local modifications in a cloned repository are not preserved by default on a second run. The README's advice is straightforward: rename the directory or set the `--no-clean` flag on future clones if you intend to work in there.

This is a defensible default for the tool's main job, where a directory is a mirror rather than a workspace, and it would be a bad default for anything else. It also explains why the reclone workflow exists at all. A backup or a scheduled sync wants the mirror semantics; a workspace wants something that leaves your work alone. Anyone adopting ghorg for the first time should decide which of those they are before running it, because the default assumes mirror.

Installation across five package managers

The README offers five installation routes and gives a command for each, which is generous coverage for a single binary tool. Prebuilt binaries are linked from the latest release page for Mac, Windows and Linux, with a note that x86_64 is probably the one you want if you are unsure.

The others are one line each:

brew install ghorg

Homebrew, mise and Go install cover the three most common developer setups. The Go route expects `$HOME/go/bin` on your path:

go install github.com/gabrie30/ghorg@latest

And mise, which the README recommends for Linux, MacOS and Windows alike:

mise use -g ghorg@latest

Docker is the sixth option and the tree contains a `Dockerfile`. That file is worth reading on its own because it encodes assumptions about how the tool is meant to run in a scheduled context. It sets `XDG_CONFIG_HOME=/config`, `GHORG_CONFIG=/config/conf.yaml`, `GHORG_RECLONE_PATH=/config/reclone.yaml` and `GHORG_ABSOLUTE_PATH_TO_CLONE_TO=/data`, runs as a non-root user with UID 1111, and ships both sample config files into place at build time. The entrypoint goes through `tini`, and the default command is `--help`.

Configuration precedence and multiple setups

Configuration is a YAML file at `$HOME/.config/ghorg/conf.yaml`, and the precedence rule is stated directly: command line flags first, then whatever is set in the config file. ghorg also respects the `XDG_CONFIG_HOME` environment variable when it is set, so the config location is not hardcoded.

The setup instructions fetch the sample configuration rather than asking you to write one:

mkdir -p $HOME/.config/ghorg
curl https://raw.githubusercontent.com/gabrie30/ghorg/master/sample-conf.yaml > $HOME/.config/ghorg/conf.yaml
vi $HOME/.config/ghorg/conf.yaml # To update your configuration

That same block appears twice in the README, once under installation and once under configuration. The Makefile has a matching `install` target that copies `sample-conf.yaml` into the same place, so there are three routes to the same starting point.

Two details are worth planning around. An API token is always required even when ghorg falls back to its defaults, and alternative configuration files can only be referenced with the `--config` flag. That is what makes cloning from several providers with different tokens practical, since each gets its own file.

Reclone, hooks and the release cadence

The high level feature list names seven things beyond basic cloning: filtering to specific repositories, backups, the `reclone` command for simplifying complex clone commands, starting clones over HTTP with `examples/reclone-server.md`, scheduling with cron via `examples/reclone-cron.md`, and tracking clone metrics over time. The `examples/` directory in the tree backs all of that up, with separate files per provider plus hooks, profiling, cron and server documentation.

The release notes show a project adding features at a steady rate. Version 1.11.15, published on 2026-08-26, added `GHORG_TRACE` and `GHORG_PPROF` for profiling and `GHORG_REPO_FILTER_HOOK` so users can run custom filters or mutate repository data, and fixed bare repositories being skipped during pruning. Version 1.11.14 added first class Codeberg support with its own token variable and a base URL override, and fixed wiki clones that assumed a `master` branch. Version 1.11.13 added a `token_cmd` option to `reclone.yaml`.

The repo also carries `SECURITY.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` and a `.goreleaser.yml`, which is what a released cross platform Go binary is normally expected to have.

Editorial conclusion

ghorg is a good fit for the two jobs it names in its own list of use cases: getting a searchable local copy of a codebase, and keeping a backup that a cron job refreshes. Six providers are supported through a single `--scm` flag, configuration is a YAML file with command line flags taking precedence, and version 1.11.15 shipped on 2026-08-26. The thing to read before your first run is the warning about the default clean behaviour, because the tool overwrites local changes in a clone directory unless you pass `--no-clean` or work somewhere else. Start by copying `sample-conf.yaml` into `$HOME/.config/ghorg/conf.yaml`, set your token, and try it against a small org before pointing it at anything large.

Frequently asked questions

Official sources

1. gabrie30/ghorg on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases