Merget and Git
The first question every engineer asks. The answer: Merget is its own version control system, and it coexists with Git rather than replacing it.
What that means in practice
Merget keeps its own complete history: its own object store and references,
inside the .merget/ folder of your repo. It does not read or write your Git
history during normal work. A repo can have both .merget/ and .git/ side by
side; Merget ignores .git/, and Git (via .gitignore) should ignore .merget/.
- You can keep using Git for whatever your team already uses it for: GitHub PRs, CI, deployment. Merget keeps its own history separately and never writes to your Git repo or pushes to your Git remotes on your behalf.
- You can import Git history into Merget: one command,
merget import git(or "Import Local Git" on the Dashboard), covers both directions: run it inside a repo to link it to Merget and pull in its local.githistory, or point it at a remote URL with--urlto clone and import a Git repo from GitHub, GitLab, and the like. Each imported commit becomes a goal, with prompts and steps reconstructed inside it from the commit message and diff; the original authorship is preserved. - You can link a GitHub repo so Merget knows where its Git counterpart lives.
What Merget does differently
| Git concept | Merget |
|---|---|
| Commit | Step - an atomic change. The why behind it lives in the prompt and goal it belongs to, not in the step itself. |
| Branch | A Git branch is two things at once - a name and a divergent line of work. Merget splits them: a fork is the divergent line (it rejoins through a merge), and a bookmark is just a name you move deliberately. See the history model. |
| Commit message | Written for you: steps get headlines, and goals/prompts give the why a structure. |
Staging area (git add) | None. Committing is automatic (or one Commit button in manual mode). There's nothing to stage. |
rebase / cherry-pick / stash | None. History is immutable; lines combine by merging. |
blame | merget blame - but it answers with the prompt behind a line, not just a name and date. |
| Object IDs | Content-addressed object IDs, the same idea as Git's. |
Under the hood
The storage model will feel familiar if you know Git internals: immutable content-addressed objects (file blobs, directory trees, and the goal/prompt/step objects) plus named refs. The differences are what's in the graph (intent objects and transcripts are first-class, not commit-message conventions) and what's deliberately absent: no index, no mutable history operations. If you can't rewrite history, you don't need the tooling for rewriting history safely.
Which one is "the truth"?
For a repo you work on with Merget, treat Merget as the source of truth for history and intent, and Git as an export/interop surface. The agent skill shipped with Merget teaches your coding agent the same rule: in a Merget repo, agents commit, check out, and merge through Merget. See Your agent and Merget.
What Merget doesn't try to be
- It is not a Git client; it won't run your Git workflows for you.
- It doesn't sync through Git remotes. Merget repos sync through Merget remotes.
- It can't recover intent that was never recorded. When you import Git history, Merget reconstructs a goal-and-prompt structure from each commit's message and diff - but that's derived after the fact, not the real prompts behind the work. Capturing the genuine why starts the day you start using Merget.
Next: Sync & privacy | Related: Dashboard (importing) | The history model | CLI reference