Project-first navigation
Move through the repository like a file explorer. Every file and folder carries its Git state, history and relevant actions with it.
Engineering tool · Private preview
See the repository.
Not just the log.
Git Integrity turns branches, files, commits and submodules into one navigable workspace. It is designed for the moment a repository becomes too important—and too interconnected—to manage from disconnected commands.
< 8 MB macOS buildmacOS + Windows portable appsNo runtime setup for the user
Inside the product
One repository. Four connected views.
Real screens from the private preview. Open any image to inspect the interface at full size.
Work through a repository like a project, with the active branch, file state and submodules visible in the same place.
Compare the same repository location against a cached server snapshot without a second checkout.
Select individual changes while keeping the repository and current branch in view.
Inspect state, change versions, manage branches, commit and publish without losing the parent repository context.
Why it exists
Git is precise.
Its interfaces are not always clear.
A branch graph should show where work actually split. A submodule should look and behave like a repository, not an obscure folder. A commit should be scoped to the file or module you are working on—not assembled from a global list you have to mentally filter.
Git Integrity keeps Git terminology and Git semantics. The difference is the visual model: larger nodes, explicit parent relationships, clear local/server state and actions placed where the work is.
HistoryBranches split only when history splits
CommitsWhole project, folder or single file
CompareLocal and server, one synchronized view
SubmodulesBrowse, branch, commit, push, replace
DeliverySmall native application
What makes it different
Repository work, kept in context
Each capability is useful on its own. Together, they remove the context switching that makes Git feel harder than it is.
Scoped commits
Commit the current file, the current folder or a deliberate selection. Local-only files stay local when deleted; tracked deletions become explicit changes.
Readable branch history
Linear history stays linear. A new lane appears only when a branch actually splits, and merges show every parent without decorative noise.
First-class submodules
See a submodule's own branch, commits and server state. Change version, create a branch, commit inside it, push it and update the parent link.
Local ↔ remote comparison
Browse the same location on both sides without cloning the server again. Differences are marked and both files scroll as one comparison.
Safe, explicit operations
Restore, stage, delete, publish and reset actions explain their scope before they run. The result is refreshed where you are working.
The submodule workflow
The hard part of Git,
made visible.
Git Integrity treats a submodule as two connected repositories. It shows what changed inside the submodule and what the parent repository records, so the two commits are never confused.
- 1Work inside the submoduleEdit, inspect history and commit in its own repository.
- 2Publish the submodulePush its branch and verify the server revision.
- 3Record the new pointerThe parent repository exposes the submodule bump as its own change.
- 4Publish the parentOne final commit makes the relationship reproducible for everyone.
Private preview
Before you ask for a demo
Is it another Electron application?
No. The desktop application uses the operating system webview and a native Git backend, keeping the delivered build under 8 MB on macOS.
Does the user need Node.js or Rust?
No. Those are build-time technologies. The delivered macOS and Windows applications are intended to run without a development environment.
Can it work with private repositories?
Yes. HTTPS credentials can be supplied for the operation that needs them, and SSH can use the system agent. Credentials are not stored by Git Integrity.
Is the source repository public?
Not yet. The product is in private preview while the workflows and packaging are being hardened. We prefer to show the working application before publishing a repository that still needs release documentation.
Next step
Bring a repository
that is hard to explain.
We will use the demo to walk through its branches, submodules and local/server state. No prepared toy repository required.