VibeHub vs git: versioning the prompt, not just the diff
vb CLI is a git superset — every vibe wraps a real git commit and adds the spec, prompts, agent transcript, model config, and eval that produced it. If nobody needs to see how AI-written code was made, plain git is all you need.Last reviewed 2026-10-31
| Feature | VibeHub | git |
|---|---|---|
| Versions code | Yes — every vibe wraps a real git commit | Yes |
| Stores prompts & agent transcript | Yes — captured on vb commit | Only what you paste into the commit message |
| Stores model & config | Yes — part of the vibe object | No |
| Eval result stored with the change | Yes — status, score, duration | No (lives in CI, separate from history) |
| Works offline, fully local | Git operations yes; capture uploads to VibeHub | Yes |
| Commands to learn | Same shape as git; unknown commands fall through to git | Just git |
| Hosting | VibeHub, mirrored to GitHub on vb push | Any remote you like |
| Cost | CLI free; transcript-captured commit costs 1 credit | Free, open source |
What git does well
Git is the standard for a reason: it is free, fully local, works with every host and CI system, and every developer already knows it. For code written by humans, a diff plus a good commit message is usually enough history.
Git versions text files. It does not know that a change came from an agent, which prompt produced it, which model ran, or whether an eval passed. You can paste some of that into a commit message, but it is unstructured and easy to skip.
What VibeHub adds on top
A vibe is a content-addressed bundle of the spec, prompts, agent transcript, model config, code diff, eval result, and deployed artifact. vb commit -m does everything git commit does, then captures the open agent session and attaches it to the commit.
Because the context travels with the commit, vb show <sha> returns the message, diffstat, and the conversation that produced it, and vb log lists commits with their conversation message counts. Reviewers see why a change exists, not just what changed.
Using them together
You do not choose one over the other. vb init registers an existing git repo as a VibeHub project — no migration — and any command vb does not recognise falls through to plain git. Teammates still on plain git are not affected.
vb push runs a normal git push to origin and then mirrors to a linked GitHub repo, so CI, code review, and the rest of your tooling stay where they are.
Choose git if…
- Your code is mostly hand-written and a diff plus commit message tells the whole story.
- You need everything to stay strictly local or on your own infrastructure.
- You do not want another account, token, or credit balance in your workflow.
Choose VibeHub if…
- Agents write a meaningful share of your code and reviewers need to see the prompts behind it.
- You want to fork or roll back the spec and prompts, not just the code.
- You want to keep git and GitHub exactly as they are and add the AI context on top.
Questions, answered.
- Do I have to stop using git to use VibeHub?
- No.
vbis a git superset: every vibe wraps a real git commit, unknown commands fall through to git, andvb pushmirrors to GitHub. Teammates on plain git are unaffected. - Can I just put the prompt in my commit message instead?
- You can, and for small changes that may be enough. It breaks down for long agent sessions with many tool calls, and it does not capture the model config or eval result in a structured way you can fork or query.
- Is VibeHub free?
- The
vbCLI, public vibes, GitHub mirroring, and reading the dashboard are free. Transcript-captured commits cost 1 credit each; credits never expire.
More comparisons
Version the whole vibe.
The vb CLI, public vibes, and GitHub mirroring are free forever.