Live, pre-merge conflict visibility over your real Git state, self-hosted and read-only, so nothing about your workflow changes.
Open source · self-hosted · read-only on your Git.
For small-to-mid engineering teams running parallel branches who want conflict visibility without changing how they use Git.
19%
of merge attempts produce conflicts
Brindescu et al. 2020, 143 projects
26×
more error-prone when resolved manually
Ghiotto et al., IEEE TSE
11%
of dev time spent actually writing code
Microsoft Research
By the time a conflict shows up, the overlapping work is already committed on both sides. The cost was paid long before anyone saw it.
The information needed to catch the overlap exists the moment two people start typing. Nobody is looking at it yet.
GitLive, GitKraken Team View, and built-in merge editors solve adjacent problems differently.
vs GitLive
GitLive is closed-source SaaS that routes your editing activity through their infrastructure. Lightning Git is open source and runs on your own server, so overlay data never leaves your network. It also goes past gutter indicators, showing grouped conflict hunks with per-contributor versions side by side.
vs GitKraken
GitKraken's Team View is a full Git client that replaces your workflow. Lightning Git layers on top of VS Code and any Git host without changing how you commit, push, or review.
vs merge-time tooling
VS Code's merge editor and tools like Beyond Compare only activate after you attempt a merge, when the overlap is already committed on both sides. Lightning Git surfaces conflicts live as teammates type, before anyone commits.
One capability sits at the center of everything else: pre-merge conflict detection over live edits.
Everything that supports the live conflict view, kept deliberately secondary.
01
Point a project at a Git remote. The backend clones it once and fetches on every open, so the read-only mirror stays current.
02
Each remote branch is registered on a simple board, derived from refs you already have. No separate ticket tracker needed.
03
The editor opens a WebSocket per file. The server pushes a snapshot of active editors and comments, then streams every change.
04
As teammates type, the backend diffs every branch against main and pushes overlapping hunks to the file's channel, before anyone commits.
Three guarantees enforced at implementation level.
Read-only
The codebase only runs clone , fetch , show , ls-tree , and branch -r . No push, no commit, no checkout exists anywhere in the backend.
In-memory
Live overlay state is held in server memory, keyed per project and user. On restart it's gone; uncommitted work never touches a database or disk.
Project-isolated
Every WebSocket message is membership-checked before broadcast. Users are scoped to their project; org permissions gate access underneath.
The thesis ships first. Everything below follows.
Commits and merges move cards across columns automatically instead of requiring manual drag.
When a conflict is detected, a teammate can propose their version as a replacement directly in the overlay. If the other side accepts, both branches converge on the same content and the conflict disappears before either of them merges.
GitLab, Bitbucket, Codeberg, and self-hosted Git servers alongside GitHub.
Comments currently live in memory and are gone on restart. Storing them in the database lets conversations survive across sessions.
Rate limiting, audit logging, token rotation, and guardrails against accidentally exposing repository content through the overlay layer.
Self-hosting docs, Docker images, and an optional managed hosting setup for teams who don't want to run their own infrastructure.
Built as a Swiss HF diploma project. Reach out if you want to talk.