git-fire

What is git-fire?

git-fire is a command-line tool for repository lifecycle management across many Git repositories. Its core purpose is to let you “checkpoint” multiple repos with one consistent workflow: it can discover repositories, optionally auto-commit dirty changes, and push backup branches/remotes with safety rails so local-only work isn’t lost.

The project is positioned for situations where making a reliable, auditable move across many repos matters—such as when you need a consistent recovery path and want to avoid manual push loops that can fail (for example due to network drops, authentication issues, or shell mistakes). The project is currently in beta.

Key Features

• Multi-repo checkpointing in one command: discovers repositories, then performs a backup-oriented push sequence instead of requiring per-repo manual steps.
• Optional auto-commit of dirty work: can create commits from local changes when enabled (the default workflow is described as auto-committing dirty work unless disabled).
• Backup branch/remote push behavior: pushes backup branches/remotes as part of the checkpoint so work has a recoverable location.
• Safety rails and auditable recovery path: designed to provide a consistent, inspectable recovery move across many repositories.
• Dry-run preview mode: supports a “preview first (safe)” approach via --dry-run to observe what the tool would do.
• Emergency one-line bootstrap script mode: an “emergency bootstrap script” path is described for urgent situations, with guidance to inspect scripts/emergency.sh first.
• TUI and configuration behaviors: the repository documentation includes a TUI (with screenshots and “color profiles”) plus a dedicated “Configuration and Behaviors” section.

How to Use git-fire

1. Install git-fire using one of the documented methods: Homebrew (macOS/Linuxbrew), WinGet (Windows), a Linux install script, native Linux packages (.deb/.rpm), or Go install.
2. (Recommended) Preview changes first: run git-fire --dry-run --path ~/projects to review the checkpoint behavior without making the backup pushes.
3. Run the default checkpoint workflow: execute git-fire to perform the standard multi-repo streamed checkpoint described in the repository README.
4. For urgent situations, use the emergency bootstrap script approach only after inspecting scripts/emergency.sh, and prefer release assets plus checksums when possible.

Note: the project states that git-fire and git fire are equivalent when git-fire is on your PATH.

Use Cases

• Backup across many repos before a high-risk change: use git-fire to checkpoint multiple repositories in one consistent workflow rather than running repetitive per-repo push steps.
• Recovering from authentication/network issues with a single planned action: when manual push loops are error-prone, use git-fire’s backup-oriented flow to create an auditable, recoverable checkpoint across repos.
• Checkpointing a workspace subset: use --path to target a directory (example given: --dry-run --path ~/projects) when you want to scope the multi-repo operation.
• Emergency bootstrap when you cannot wait for a standard install: follow the “In case of fire” approach to bootstrap an emergency path, using RELEASE_TAG in the command as shown in the documentation.
• Teams standardizing repository lifecycle steps: use git-fire’s documented core promise and safety rails to keep multi-repo checkpoint procedures consistent across environments.

FAQ

• Is git-fire production-ready? The project explicitly states it is beta software. It notes that core multi-repo backup flows are usable today, while some roadmap items are not yet wired (for example --backup-to and USB destination mode).

• Can I preview what git-fire will do before making changes? Yes. The README shows git-fire --dry-run --path ~/projects as a “preview first (safe)” step.

• How does the emergency bootstrap work? The README provides a one-line command that downloads and executes scripts/emergency.sh from the repository at a given RELEASE_TAG. It advises inspecting scripts/emergency.sh first and mentions that curl | bash executes remote code directly.

• What install methods are available? The README lists Homebrew, WinGet, a Linux install script, Linux native packages (.deb/.rpm), Go install, and binary archives from GitHub Releases.

• What does “one command” include? The documented core promise is to discover repos, auto-commit dirty work (unless disabled), and push backups so local-only work is not lost.

Alternatives

• Standard Git workflows with per-repo scripts: you can write your own shell loops around git status, git commit, and git push, but this shifts the burden of consistency and error handling to you—precisely the failure modes git-fire aims to reduce.
• General-purpose multi-repo Git tooling (repo management utilities): these may help iterate over many repositories, but git-fire is specifically oriented around checkpointing with backup branches/remotes and the described safety rails.
• Manual backup branch creation per repository: this is straightforward but can be tedious and easier to get wrong across many repos, especially when authentication or network issues occur.
• GUI Git clients with batch operations: some clients provide batch actions across repositories, but the README’s emphasis on an emergency bootstrap, dry-run preview, and consistent auditable checkpoint flow may differ from GUI-focused workflows.