Claim it before you touch it: how Gitby prevents merge conflicts
Two people on a team open index.html on the same afternoon, and neither knows about the other. If their edits overlap, whoever pushes second gets told to pull first. The pull stops on a conflict, and somebody spends the next while reading two versions of the same lines and guessing what the other person meant.
Git isn't doing anything wrong there. It compares changes once they exist, and by then the expensive part has already happened.
Most teams patch this socially. Someone posts "anyone in index.html?" in chat, someone answers, and it works right up until the day nobody asks.
We built Gitby to take that question out of chat and put it in the repository. You claim a file before you edit it, everyone on the team sees your name on it, and the file stays read-only for them until you let go.
What a claim does
Gitby is a terminal app for macOS, Linux and Windows that sits on top of GitHub. Run gitby, pick a repository, and you get a file list with everyone's claims on it. Press e on a file and it's yours: your name shows up in every teammate's terminal and on the web dashboard, on that branch, until you release it with r. You can claim one file, a whole folder, or the entire repository if you're about to do something drastic.
The read-only part is plain old file permissions. Gitby changes the permissions your operating system already enforces, so it doesn't matter which editor anyone uses, and there's no plugin to install. If you try to save a file someone else holds, your editor will complain that it can't write to it, and now you'll know why.
It's a guardrail against accidents, and it only applies while Gitby is running. Anyone determined to edit a file can still get around it.
By default, every file you haven't claimed is read-only. That's the strict setting. If it's too much for your team, switch the repository to claim-on-edit: files stay writable, and Gitby claims each one for you as you start editing.
Asking for a file someone else has
When you need a file a teammate holds, press t to ask for it. They press a to hand it over or d to say no. Here's roughly what you see while it's theirs:
index.html claimed by @mark
Gitby: claimed by @mark. Request access to edit.
If a handoff needs a conversation first, team chat sits right next to the file list on the paid plans. Every request, grant and denial gets logged with who did it and when, so there's a record of who held a file and who asked for it.
Claims don't end because your laptop went to sleep. A claim stays yours until you release it, hand it off, or a team owner steps in. If you've been gone longer than the team's threshold, the file list marks it stale so people know to ask.
You won't need a second terminal
Gitby also handles the git side. Commit, push, switch branches, revert, sync file by file with a merge step, and look through diffs, the commit graph, the reflog and your worktrees, all from the same window. There's a terminal pane for everything else.
One thing it does that plain git won't: if a push includes a file you don't hold, Gitby stops it before it leaves your machine.
You can also pin notes to a file or a specific line. If a route shouldn't change until the API update lands, put that on the file, and whoever opens it next reads it first.
Coding agents play by the same rules. They connect over MCP, claim and release files under your account, and propose each claim with a reason you approve on the Agents page, unless you run them with full access. Agent support is still in validation, so it isn't on any plan yet. An agent can already install Gitby for you, though, by following gitby.dev/get-started.md.
What your team lead sees
The web dashboard shows the repository live: who holds what, who's online, the team chat and any requests waiting on you. It also counts how the team shares the repo, including claims, handoffs, hold times, contention, stale claims and which paths change hands most.
Those numbers stay at team level. Durations are medians rather than averages, there are no per-person leaderboards, and your own breakdown is visible only to you. File contents, diffs, note text and chat messages never go into the stats.
We're picky about the "conflicts prevented" count. It only goes up when a second person wanted a file you held (they requested it, opened it in an editor, or tried to push it) and the file reached a commit with one holder first. A toast notification popping up doesn't count. We're still checking these numbers against live teams, so the dashboard doesn't show them yet.
Your code stays on GitHub
Gitby doesn't replace GitHub. Your repositories stay there, you keep using git, and Gitby connects through your GitHub account.
We never store your code. Pushes made through Gitby pass through our push service on the way to GitHub without a copy being kept, and the dashboard's diff view fetches changes from GitHub for your browser. What we do store is coordination data: paths, claims, requests, notes, team membership and activity.
Pricing and install
Gitby is free for up to 3 people and 2 repositories. After that you pay per team, never per seat:
| Plan | Price per team / month | Teammates | Repositories |
|---|---|---|---|
| Free | $0 | 3 | 2 |
| Starter | $7.99 | 5 | 5 |
| Team | $14.99 | 8 | 10 |
| Team+ | $36.99 | 20 | 30 |
| Enterprise | $89.99 | 50 | 100 |
Team chat starts on Starter, and Team+ adds priority support. If you need more than Enterprise, talk to us about a custom plan.
On macOS or Linux:
curl -fsSL https://github.com/GITBY-SOFTWARE/downloads/releases/latest/download/install.sh | sh
On Windows, in PowerShell:
irm https://github.com/GITBY-SOFTWARE/downloads/releases/latest/download/install.ps1 | iex
Then run gitby, sign in, pick a repository, and press e on whatever you're about to change.
The docs on gitby.dev cover claims, handoffs and agents over MCP in more detail. If something breaks or you want a feature, tell us at gitby.dev/issues or on Discord.
Top comments (2)
Early visibility into overlapping edits can reduce surprises, but the handoff matters too: how are abandoned claims expired or released when someone goes offline? A stale claim can otherwise become its own coordination bottleneck.
Good question.
In Gitby, a claim never expires on its own, by design: a claim that silently drops can let two people edit the same file. When someone goes offline, their files are marked offline for everyone. Anyone waiting can send a request that the holder answers when they're back. If it can't wait, an owner or someone with the right role can release the claim or answer for them, and that's recorded under their name.