# RelaGit is an Electron git client that shells out to the git CLI

> RelaGit is a TypeScript and SolidJS desktop git client distributed for macOS, Windows and Linux, with a workflow system, host integrations for GitHub, GitLab and Codeberg, and an AI assistant wired to several model providers. It fits a developer who wants a graphical view of a repository, and it does not fit a team that needs merge conflict resolution or a server-side component, since the roadmap still lists libgit2 as an open item.

**relagit/relagit** — The elegant solution to graphical version control.

- Repository: https://github.com/relagit/relagit
- Website: https://rela.dev
- Stars: 1,119 · Forks: 34
- Language: TypeScript
- License: LGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/relagit-relagit

## It is an Electron app, and it drives the git CLI rather than a library

RelaGit describes itself as the elegant solution to graphical version control, and the package description is more specific: take back control over your git workflow. The homepage is rela.dev.

The technical shape is a TypeScript Electron application. The package.json names electron-vite as the dev server and builder, with the scripts start running electron-vite preview, dev running electron-vite dev, and build running electron-vite build. The main entry is ./dist/main/index.js and the package is type module. The UI is SolidJS, which the repository topics list, and the configuration splits into tsconfig.json, tsconfig.node.json and tsconfig.web.json, which is the usual Electron split between the main process and the renderer.

The decision that shapes everything is in the roadmap. Use libgit2 for git operations instead of the git CLI is listed as an open question, which tells you the current implementation shells out to the git binary. The Building section lists Git as a prerequisite alongside Node.js v18 or higher and pnpm, which confirms it.

That is a defensible choice for a first release. The git CLI is present on any machine where the user is a developer, its behaviour is the behaviour every developer already knows, and libgit2 is a large native dependency to embed. It is also the reason for the other roadmap item, optimisation of git processes and operations, currently there is noticable CPU strain on startup, which is marked as done.

The last push was on 2026-08-09, with the newest release v0.16.11 from 2026-04-30, and the licence is LGPL-3.0-or-later.

## Installs are per platform, and there are five of them

Builds are generated automatically upon release, and the README lists the artefacts for five platform combinations.

For macOS there is a separate download for Intel, RelaGit-mac-x64.dmg, and one for Apple Silicon, RelaGit-mac-arm64.dmg. For Windows it is a zip, RelaGit-win.zip. For Linux there are three package formats, an rpm, a tar.gz and a deb, named RelaGit-linux.rpm, RelaGit-linux.tar.gz and RelaGit-linux.deb.

That is a broad target matrix for a project in beta, and it is worth noticing that the two macOS builds are separate rather than a universal binary. The Apple Silicon and Intel downloads are distinct artefacts, which means a distribution channel has to pick the right one and the project has to keep both building.

Building from source needs Node.js v18 or higher, pnpm and Git, and the sequence is short:

```bash
git clone https://github.com/relagit/relagit relagit

cd relagit

pnpm i
pnpm build
pnpm make:{platform}
```

The platform placeholder is replaced with one of the supported platforms, for example make:mac, and the executable ends up in the out folder. The package scripts show the variants available, make:mac, make:win and make:linux, plus CI-specific ones named make:macos-latest, make:windows-latest and make:ubuntu-latest that build without the arch or target pinning.

The build itself is electron-builder with a shared builder.cjs config, and there is a postinstall script that runs node ./build/icons.mjs, which is what generates the platform icon sets for a given target.

## Workflows are the feature the project is organised around

The README's documentation pointer is the Creating Workflows tutorial, and that tells you what the product model is. A workflow is a named sequence of git operations that the user invokes, rather than clicking through a series of dialogs, and the tutorial is where the semantics of that abstraction are defined.

This is a meaningful design choice for a git client, and it is the one that distinguishes this kind of tool from a file browser with a history view. The mental model is closer to a build pipeline for your repository than to a traditional IDE panel, and it scales to the repetitive multi-step operations that dominate real work, such as rebasing a branch onto a moving target, creating a branch and pushing it in one action, or amending and force-pushing with the amend flag set.

The roadmap shows the same orientation. Two of the three completed items are about correctness and speed of the underlying operations, support for git submodules and optimisation of git processes, and the third adds a commit graph in the information modal.

The information modal and the commit graph deserve a note, because the commit graph is a feature most git GUIs either get wrong or omit. Rendering the actual DAG of the commit history, with merge structure, rather than a flat chronological list, is what makes a graphical client worth using over the command line for understanding a repository's shape. That it is listed as done is a good sign.

The README also notes the project is in an early beta stage and asks for issue reports, which is the honest way to describe a client that is functional but not yet stable.

## Hosting integrations use OAuth client ids, and there is a pattern to it

The .env.example file at the repository root is short and reveals the shape of the host integration:

```
GITHUB_CLIENT_ID=abc
GITLAB_CLIENT_ID=abc
CODEBERG_CLIENT_ID=abc
AI_API_PASSWORD=abc
AI_API_URL=abc
```

Three OAuth client ids for GitHub, GitLab and Codeberg, and two settings for the AI assistant's endpoint and password. The three hosting providers are the same set that appears in the client id list, which suggests the hosting layer is pluggable across the major forges rather than hardcoded to one.

The AI integration is the more substantial piece. The package.json carries the Vercel AI SDK packages, with @ai-sdk/anthropic, @ai-sdk/google and @ai-sdk/openai all listed, alongside the ai package itself at version 7. The presence of three providers in one build is the interesting part, because it means the assistant is not tied to a single vendor, and the AI_API_URL and AI_API_PASSWORD environment variables suggest there is also a self-hosted or custom endpoint path, which is the configuration most teams would want when source code is involved.

The @sentry/electron dependency handles crash reporting for the desktop build, and electron-updater handles the update channel. Both are the kind of dependency that says the project expects to ship to end users rather than to developers who build from source.

## The licence splits code from brand assets

The licensing section has two parts, and the second one is unusual enough to be worth reading carefully.

The first part is the standard one. All files, unless otherwise stated, are licensed under the Lesser GPL v3.0 or later, with a copy of the license in the LICENSE file, and the package.json records license as LGPL-3.0-or-later.

The second part restricts the assets rather than the code. All assets which contain RelaGit brand images are property of the Rela organisation and may not be used without permission, and the README links to the branding documentation on rela.dev.

That split is worth understanding for a real adoption decision. The LGPL is a weak copyleft licence: if you modify the application and distribute it, your modifications to the library must be available, but a separate work that merely uses it through its interface is not affected. For a desktop application that most people will run rather than redistribute, that is an easy licence to live with.

The branding clause is the part that catches teams who want to fork. You can take the code, change it, and ship it under the LGPL terms, but you cannot ship the icon and the name. For an internal tool at a company that rebrands its tooling, that is the line to check.

The build/ directory also holds an icons.mjs script, which is the code that generates the platform icon sets from those brand assets, and the fact that it runs on postinstall means the icons are produced from the source rather than committed per platform.

## Where RelaGit is the wrong tool

The first wrong-tool case is heavy merge conflict resolution. The feature list in the README, which is largely the workflow system plus the information modal and the commit graph, does not describe a three-way merge tool with a diff editor, and the roadmap does not list one. A developer whose daily work is resolving conflicts lives in the diff view, and this client does not claim to be that.

The second is a team that needs GitHub or GitLab pull request workflows. The client has OAuth client ids for those hosts, which is an authentication integration, not a pull request review client. Opening a PR, reviewing a diff on the forge, and managing branches through the forge's web interface are all still forge-side tasks.

The third is the beta status combined with a shelled-out git. The project says it is in an early beta stage, and the git CLI dependency means the behaviour of the client depends on the git version installed on the machine. A user on an old git, or a corporate build with a patched git, can get different results from the same client. That is manageable and common, but it is a variable a team has to own.

The fourth is a headless or remote workflow. This is a desktop application that needs a local checkout. A team whose work happens on a remote server, in a browser-based IDE, or in a container, is not going to run it there, and the project has no server component or terminal client described anywhere in the documentation.

## Conclusion

RelaGit fits a developer who wants a graphical view of repository history and branch state, and it does not fit a team whose daily work is heavy conflict resolution or who needs a stable release. Before adopting it, note that the project states it is in an early beta stage, and check whether the roadmap item on replacing the git CLI with libgit2 affects your plans, since today the client depends on the git binary being installed.

## FAQ

### What is RelaGit and what does it do?

RelaGit is a desktop git client described as the elegant solution to graphical version control. It is a TypeScript Electron application with a SolidJS interface, distributed for macOS on Intel and Apple Silicon, Windows and Linux, and organised around user-defined workflows rather than a sequence of dialogs.

### How do I build RelaGit from source?

You need Node.js v18 or higher, pnpm and Git. Run git clone https://github.com/relagit/relagit relagit, cd relagit, then pnpm i, pnpm build and pnpm make:{platform} with the platform replaced by one of the supported values such as make:mac. The executable ends up in the out folder.

### Does RelaGit use libgit2 or the git command line?

The git command line. Git is listed as a build prerequisite, and the roadmap lists use libgit2 for git operations instead of the git CLI as an open item. The roadmap does mark as done the optimisation of git processes and operations, which it notes previously caused noticeable CPU strain on startup.

### What licence is RelaGit released under?

All files, unless otherwise stated, are licensed under the Lesser GPL v3.0 or later, with the copy of the license in the LICENSE file. Separately, assets containing RelaGit brand images are property of the Rela organisation and may not be used without permission.

## Sources

- [License: LGPL-3.0](https://github.com/relagit/relagit/blob/main/LICENSE)
- [Project website](https://rela.dev)
- [README](https://github.com/relagit/relagit/blob/main/README.md)
- [relagit/relagit on GitHub](https://github.com/relagit/relagit)
- [Releases](https://github.com/relagit/relagit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/relagit-relagit