The clone-and-read half is the unusual part: hand it a URL and it fetches the repository into a deterministic temporary directory, reuses that on the next question, and lets you walk the tree, read files and search code without cloning anything yourself. The rest is a full Git surface including the destructive end — reset, clean and rebase are all here — so your local credentials are the boundary.
A Git server with two halves. It clones a repository by URL to inspect its tree, files, history and diffs, and it operates on a working copy — branches, commits, staging, push and pull, stash, tags, rebase, reset and revert.
- A repository's directory tree as an ASCII outline, and the contents of the files you name
- Code searched by pattern across a repository, with file filters, case sensitivity and context lines
- Commit history filtered by author, date range or message, and full commits with their diffs
- Two branches compared, with the changed files and optionally the patch
- Branches created, checked out, merged and deleted
- Files staged and committed, uncommitted changes read back, and work stashed or restored
- Push and pull against a remote, tags created, and archives produced as zip or tar
- Blame, clean, reset, revert and rebase
- Hooks, attributes, repository configuration, and Git LFS objects managed
Git installed on the machine and Node to run the server. No account and no key — it operates with whatever access your local Git credentials already have. Cloned repositories land in a temporary directory keyed by the URL and are reused on later calls.
One command — npm install -g git-commands-mcp