Introduction
Gitwright is a free Git client: a desktop application that runs the Git commands you already know and shows the result in a native interface. It is written in Go with native controls, ships as one binary, and does not embed a browser engine or a JavaScript runtime.
It is a client, not a replacement for Git. Every operation is executed through the git binary installed on your machine, so the repository, the index, hooks, attributes and configuration are exactly the ones your terminal sees.
Who it is for
- Developers who are comfortable with Git and want precise control over what goes into a commit.
- People who want to see a diff before staging part of it, and to undo a destructive action without hunting for the right reflog entry.
- Teams that want pull-request review, history and conflict resolution in the same window as the working tree.
- Anyone who prefers a tool that works offline and has no account.
The signature loop
The core loop is three keystrokes away at any time:
Spacestages the selected file, or the selected hunk or lines in the diff.Cmd/Ctrl + Entercommits what is staged, with the message in the composer.Cmd/Ctrl + Shift + Ppushes the current branch.
Everything else in the application supports that loop: history to find the right base, branches to switch context, recovery snapshots so a mistaken discard or force push can be undone, and files so you can read the code you are about to change.
What makes it different
Staging is bound to the diff you saw. File, hunk and line staging carry a fingerprint of the diff they were computed from. If the file changes underneath, the operation returns git_stale, writes nothing to the index and reloads the diff. You never stage a version of a hunk you did not read.
Destructive operations save a snapshot first. Discarding changes, hard reset, force-with-lease, dropping a stash and aborting a merge or rebase all write a recovery snapshot before they act. A restore refuses to overwrite a file that changed after the snapshot.
AI is optional and advisory. An ACP-compatible agent can draft a commit message, explain a diff or review a change set or branch. It cannot write files or run a terminal through the application, reviews show the scope before sending, and each review produces a receipt. The agent process itself is not sandboxed — see ACP agents.
There is no account and no cloud. No sign-in, no subscription, no synchronization service, no telemetry pipeline. Repositories, diffs, settings and snapshots stay on disk.
What stays local
| Data | Where it lives |
|---|---|
| Repositories, index, refs | Your own filesystem, managed by the system git |
| Settings, local database, logs | The platform data directory |
| Recovery snapshots | A directory inside the data directory |
| Forge tokens, agent variables, MCP token | The operating system keychain |
The application reads files and runs Git on your machine. It connects to the network only for Git remotes, a forge API you configured, an agent you configured, the loopback MCP server you enabled, or an update check. Details are in the Privacy Policy.
Requirements
- Git available on
PATH(or set an explicit binary in Settings). Without it, no repository can be opened. - macOS 12 or newer (arm64 build), Windows 10 or newer (amd64), or Linux (cross-compiled; community-tested).
- Optional:
git-lfsfor LFS repositories,ghif you publish releases from the command line. - A forge token only if you want pull-request features.
Where to go next
- Quick start — install, open a repository, make the first commit.
- Changes — how staging, discarding and the commit composer work.
- Recovery — what snapshots cover and how to restore them.
- Shortcuts — the full keyboard map.