ungit: a browser UI for git that runs on any machine with node.js

What ungit solves, and who it is actually for

Git's learning curve is the problem ungit attacks. The README makes the argument directly: git is a versatile distributed source control system used by individuals and communities, but it "is not known for userfriendliness or easy learning curve." ungit's stated goal is to bring user friendliness to git without sacrificing git's versatility. The xkcd comic embedded in the README, the one about learning git by waiting through a few minutes of "just think of branches as...", sets the tone: this is a tool for the person who has been told git is simple and does not yet believe it.

The intended audience is therefore not the developer who already lives in a terminal. It is the person who needs to see what a commit, a branch or a merge looks like as an object before the commands make sense. The README lists four selling points: a clean and intuitive UI that makes git easier to understand, support for any platform node.js and git support, a web-based design so you can run it on a cloud or shell machine and use the UI from your browser at http://your-cloud-machine.com:8448, and good behaviour with GitHub. There is also a Gerrit integration through a separate plugin repository, which tells you the project has been used in code review workflows, not only in solo repositories.

The architecture: a Node server, a browser client, and a file watcher

ungit is not a desktop application. Running the ungit command starts a Node.js server, and the README says it launches the server and opens a browser with the UI. The repository layout backs this up: there is a source/ directory, a public/ directory, a components/ directory, and a bin/ directory containing the ungit entry point. The package.json declares express as a dependency alongside express-session and body-parser, which is a conventional Node HTTP stack, and the bin field exposes two executables, ungit and 0ungit-credentials-helper.

The client side is server-rendered assets rather than a single-page framework: the dependency list includes knockout, jquery, jquery-ui, bootstrap, crossroads and diff2html. That combination is a specific design choice. diff2html means diffs are rendered in the browser as HTML rather than printed as terminal output, which is the whole point of the interface. crossroads handles client-side routing.

The auto refresh behaviour is the mechanism worth understanding. The README states that ungit watches the git directory recursively upon page view and automatically refreshes contents on git operations or changes to files that are not configured to be ignored in .gitignore. Two consequences follow. First, if you run git commands in a terminal while the ungit page is open, the page updates without a manual reload. Second, the watcher respects .gitignore, so a repository that generates large untracked directories outside .gitignore will produce more file-watching work than one that does not. The chokidar and ignore packages in the dependency list are the machinery behind that sentence.

Installing ungit and running it against a real repository

The README lists three prerequisites before installation: node.js at version 20.19.0 or higher, npm at 10.8.2 or higher (it ships with node.js), and git at 2.34.x or higher. Installation is a single global npm package.

npm install -g ungit

If your system needs root to install global npm packages, the README gives a variant with the -H flag, which preserves the invoking user's home directory so npm does not write root-owned files into it:

sudo -H npm install -g ungit

Prebuilt electron packages are also published on the releases page, but git is still required even with those. Once installed, you start it from inside the repository you want to look at:

ungit

The README says this launches the server and opens a browser with the UI. If you are running it on a remote machine, the README's own example address is http://your-cloud-machine.com:8448, so 8448 is the port to expect and to open in a firewall rule if you intend to reach it from elsewhere. Configuration lives in a JSON file named .ungitrc in your home directory, /home/USERNAME on Unix-like systems and C:/Users/USERNAME/ on Windows. The README gives this example, which changes the default port and turns on bugtracking:

{
	"port": 8080,
	"bugtracking": true
}

Any of those options can also be passed at launch, for example ungit --port=8080, and boolean features are disabled with a --no prefix, as in ungit --no-autoFetch. The README points to source/config.js for the full list of available options, which is worth reading before you write a config file, because the README itself does not enumerate them.

GPG signing: what ungit deliberately does not do

This is the clearest limitation in the documentation, and the README states it in capitals: ungit does not support GPG authentication. The distinction matters. Signing commits with a PGP key is supported, and can be enabled either by setting git config --global commit.gpgsign true, or without the global flag at the repository level, or by adding isForceGPGSign: true to the ungit configuration file. What is missing is the part where git asks for the passphrase.

The README explains why: git allows programmatic authentication through credential-helper, and the author could not find an easy equivalent for GPG. The consequence is that password-less GPG authentication, or a third-party GPG password manager, must already be configured before you use ungit to commit with a signed key. The README offers two routes: caching the GnuPG passphrase for the user session, or using gpg-agent with pinentry-mac on macOS, installed with brew install gnupg gpg-agent pinentry-mac and verified by signing a test string with gpg --clearsign. The author's own framing is that this is inconvenient but preferable to a security exposure in ungit. That is a defensible trade-off, and it is also a real cost: if your signing setup prompts interactively, committing from the ungit interface is not going to work until you change it.

Known issues and cases where ungit is the wrong tool

The README's known issues section is short and partly historical. It warns that MacOSX Mavericks users whose ungit crashes after a few seconds should update npm and node, that Ubuntu users may have trouble installing because the node executable is named differently there, and that Debian Wheezy's packaged git and nodejs are too old, so the README tells those users to download current tarballs and build from source. The first is tied to a macOS release from 2013; the other two describe distributions old enough that the stated minimums of node 20.19.0 and git 2.34.x would rule them out anyway.

The known issue with the widest reach is ad blocking. The README states plainly that an ad blocker may block ungit, naming Adblock Plus and uBlock among the examples, and the package.json includes just-detect-adblock as a dependency. If the interface loads blank or half-broken for a colleague, this is the first thing to check, and it will not show up in a server log.

The wrong-tool cases follow from the architecture. If you want a native desktop client with no local server and no browser tab, ungit is not that. If you work on repositories where a recursive file watcher over the working directory is expensive, the auto refresh design is a liability rather than a feature. And if your workflow depends on interactive GPG passphrase entry, the previous section applies.

ungit and gitk: what the difference in approach means

The natural comparison is gitk, the history browser that ships with git. Both show you commits and branches graphically, and both are launched from a repository, but they are built on opposite assumptions about where the interface lives.

gitk is a local Tk application. It draws history in a window on the machine where the repository sits, and it is primarily a viewer: you inspect history and diffs, and you go back to the terminal to change anything. ungit is a client-server application. The Node process runs on the machine holding the repository, and the interface runs in whatever browser can reach it. The README's own framing of this is that ungit is web-based, so you can run it on a cloud or pure shell machine and use the UI from your browser. That is the practical difference: ungit can be used against a remote server without X forwarding, and gitk generally cannot.

The second difference is scope. gitk is a history viewer. ungit is built around performing operations, which is why the README talks about understanding git rather than inspecting it, and why the project ships a credentials helper binary alongside the main one.

Maintenance, licence and upgrade cost

ungit is MIT licensed, with the licence text in LICENSE.md at the repository root. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice, and anyone embedding ungit in a distributed product should read LICENSE.md and the licences of its dependencies rather than rely on that summary.

On maintenance: the repository is not archived, and the last push was on 2026-09-03. The release history is uneven. v1.5.28 was published on 2024-10-03, v1.5.29 and v1.5.30 both on 2026-03-02 and 2026-03-03. So there was a gap of roughly seventeen months between v1.5.28 and v1.5.29, followed by two releases a day apart, and then commits continued into September 2026. That pattern suggests a project that moves in bursts rather than on a schedule, which is worth knowing if you are waiting on a fix.

Upgrade cost is low in normal use. The package is installed globally from npm, so npm install -g ungit picks up the current version, and configuration lives in .ungitrc and command line flags rather than in repository files. The thing to watch is the version floor: the README requires node.js 20.19.0 or higher, so an upgrade of ungit on a machine pinned to an older Node runtime will fail at install or start. The dependency list is also broad, spanning express 5, chokidar 5 and knockout, so a major bump in any of those can change behaviour in ways the release notes would have to explain.

Editorial conclusion

ungit fits developers and teams who want a visual layer over git without giving up the command line, and it is a reasonable fit for a shared remote machine where contributors browse to port 8448. It is the wrong tool if you commit with a GPG key and expect an interactive passphrase prompt, since the README states ungit does not support GPG authentication, and it is wrong for anyone who wants a graphical client installed as a desktop application rather than a local server. Before adopting it, verify three things on your own machine: that node.js is at least 20.19.0, npm at least 10.8.2 and git at least 2.34.x; that port 8448 is not already in use or is overridden in ~/.ungitrc; and that your browser's ad blocker does not block the interface, which the README lists as a known issue.

Frequently asked questions

Official sources

1. FredrikNoren/ungit on GitHub
2. Issues
3. License: MIT
4. README
5. Releases