Lightning Git mirrors your repo, tracks who is editing what, and runs conflict detection against every active branch on demand.
0%
of merge attempts produce conflicts
Brindescu et al. 2020, 143 projects
0×
more error-prone when resolved manually
Ghiotto et al., IEEE TSE
0%
of dev time spent actually writing code
Microsoft Research
Jira tickets, Slack pings, and stand-ups exist to answer one question: "What is everyone working on?" The answer is always stale by the time it lands.
Lightning Git clones your repository on project creation, fetches on every open, and layers a live editing state on top via WebSocket. No new process, no new tool to learn.
A live session is a WebSocket connection per file. Everyone editing the same file shares a channel where edits, comments, and conflict warnings flow in real time. Everything below runs on top of that.
Every user editing a file gets their own in-memory state keyed by user ID. Changes are broadcast over the session channel to everyone else on the same file, so you see what your teammates are typing without anyone's work overwriting anyone else's.
Click any edited line to leave a comment. Comments are broadcast over the same WebSocket channel, tied to line numbers, and support @mentions with autocomplete from the project member list. They're in-memory and part of the session, gone on server restart like the overlays themselves.
The backend diffs each active branch against origin/main , decomposes the changes into hunks, and groups overlapping line ranges. When two branches touch the same lines with different content, that's a conflict and it shows up before anyone merges.
One API call resets all your overlays in a project back to the base content from git. If your live state drifted or you want a clean slate, hit the emergency brake. It only affects your own overlays, everyone else's session state stays untouched.
Remote branches are detected on every fetch and registered as tasks on a Kanban board. You move them between To Do, In Progress, Review, and Merged manually. Column state is persisted so it's consistent across users and devices.
Press Ctrl+Shift+L or Cmd+Shift+L to connect. The extension sends your edits with a 1s debounce and renders teammate changes as inline peek decorations. The status bar shows who's active and whether any conflicts are predicted.
A browser-based view of the same data. Kanban board, member management, file tree with live-edit indicators, and a project-wide activity feed that shows who is editing which file on which branch.
The backend clones the repo once on project creation and fetches on every project open to stay current. The local mirror is the data source for branch listing, file reads, and diff computation. Only read-only git commands run against it.
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 fully open source and runs on your own server, so overlay data never leaves your network. It also goes further than gutter indicators by showing grouped conflict hunks with per-contributor versions side by side.
vs GitKraken
GitKraken's Team View shows who's on which branch and flags shared files, but it's a full Git client that replaces your workflow. Lightning Git sits on top of VS Code and any Git host without changing how you commit, push, or review. The Kanban board is derived from branches you already have.
vs merge-time tooling
VS Code's built-in merge editor and tools like Beyond Compare activate after you attempt a merge. By then the overlap is already committed on both sides. Lightning Git runs its diff pipeline when you open a file or when the frontend polls the merge endpoint, so you see the conflict while both contributors still have context.
01
Create a project and point it at a Git remote. The backend clones it once and runs a fetch every time someone opens the project, so the mirror stays current on demand.
02
On every fetch the backend scans remote refs and registers each branch as a Kanban task. You drag them between columns yourself, the board just removes the need for a separate ticket tracker.
03
The VS Code extension opens a WebSocket per file. The server pushes a snapshot of all active editors and comments immediately, then streams every subsequent change.
04
When you open a file the frontend calls the merge endpoint, which diffs every branch against main and flags overlapping hunks. The client also polls periodically and computes live overlap from active overlays between polls.
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 and keyed per project and per user. On restart it's gone. Nothing about uncommitted work touches a database or disk.
Project-isolated
Every WebSocket message is membership-checked before broadcast. Users are scoped to their project, and org-level permissions gate access to all projects 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 documentation, Docker images, and a managed hosted option with a paid plan 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 about it.