Keep a change (Git and merging)
Git in one minute, and how to move a finished change from the run's copy into your real project.
In simple words
A run never edits your project folder. It works in its own copy - a git worktree beside your project, on its own branch - and stops at merge_ready with the change waiting there.
Folding it into main is the one step Vibestrate always leaves to you, and the sidebar’s Source page is where you do it: Changes, Tree, Merge.
Read the diff before merging, every time. The verdict tells you which checks ran and passed, not that the change is the one you wanted. Only you can answer the second question.
Copy cd on the run page puts the worktree path on your clipboard, to read the work in your editor.
Your three options
Take it Merge the run’s branch into yours. The advisor can tell you what that would do first.
Take part of it It is a normal git branch. Cherry-pick what you want.
Leave it Ignore the folder. Nothing entered your branch, so there is nothing to undo.
The merge advice is read-only: it reads the run’s branch and recommends one of three routes, changing nothing. The merge is a separate click; finishing into main asks you to confirm first, and from the terminal needs the merge-to-main token typed out.
Git in one minute
A branch is a parallel line of work. Your real code sits on one, usually main; a new change grows on its own branch until you combine them.
A worktree is a second folder checked out to a branch. Every run gets one, so the agent edits files there, not in your project folder.
A merge folds one branch into another: the run’s branch into main is how a finished change becomes part of your project.
Run ids are short docker-style handles like bold-lovelace, so that run’s branch is vibestrate/bold-lovelace.
Read the change
Source > Changes lays out your working tree and every run’s worktree; What each run changed opens each diff file by file. Or read it where it sits:
cd ../.vibestrate-worktrees/<runId>
git diff mainAsk for advice, then integrate
Source > Merge lists every merge-ready run: how far ahead and behind main, how many files it touched, its assurance lanes. Get merge advice opens one, with risk flags first (did your checks run at all, does the change touch protected paths), then a dry-run conflict report, then one of three recommendations:
Below it, Integrate this run merges into the branch you name - integration/main to start with, never straight into main. A conflict stops it and leaves a mergeable worktree rather than half a merge. Once that branch is clean, Complete merge to main appears, asks you to confirm, and merges locally. It never pushes.
Analyze the diff, under Analyze deeper, is the optional model pass: a local provider reads the run’s redacted diff and writes advisory prose on risks a text check can’t see, like concurrency or missing tests. It never merges, never pushes, and cannot change the recommendation above it.
Plan any merge, run or not
Source > Tree draws your repo’s commit graph. Pick a source and a target in the Merge planner and press Predict for the result before it happens. A clean prediction offers Apply merge; Guided merge has the supervisor propose a resolution for a conflict, with the apply still your explicit click. Undo merge on “<target>” reverses the last merge on that branch, while it is unpushed and nothing is built on top.
From the terminal
vibe integrate advise <runId> # the same read-only advice; --json for a machine
vibe integrate preview # dry-run conflict report across merge-ready runs
vibe integrate analyze <runId> # the optional model read of the diff
vibe integrate apply --into integration/<name>
vibe integrate finish <branch> # merge to main, typed confirmation, local onlyOr use git directly. It is a normal branch:
# Open a pull request (best on a shared project)
cd ../.vibestrate-worktrees/<runId>
gh pr create
# Or merge it into main locally
git checkout main
git merge --ff-only vibestrate/<runId>To throw the change away, leave the branch alone. Nothing ever reached main.
Opening a pull request
vibe integrate pr <runId> prepares one. It resolves the branch and its base, writes the PR body from what the run recorded - the verdict, which checks passed, and whether the review was a different model or the same one checking itself - sweeps the whole outgoing diff for secrets, and prints the gh pr create line for you to run.
It stops there, and the stopping is the point. Opening a pull request requires pushing, and pushing is the one thing Vibestrate does not do. See why below.
The secret sweep is stricter here than during the run. The per-turn patch check is deliberately lenient, because a false positive there blocks work on a local branch where a missed one is harmless. Once a diff is pushed to a repo GitHub scans, that trade reverses - so this sweep uses the same broader patterns the Flow Hub uses before publishing, over the full branch diff. A finding is a refusal, not a warning: you get no command to paste until it is gone.
Merging is always your call
Merging is the moment you commit: the change joins your shared history and ships from there. A bad merge is revertible, but only after the wrong code was trusted and built on, and no model can vouch for its own work well enough to make that call for you. See the safety guarantees.
The advice is deterministic: git facts and check lanes in, recommendation out, so the same inputs always give the same answer and no supervisor persona colours it. A model enters only when you ask for the deeper read.
“Off by default” undersells it, and the difference matters if you came looking for the switch. Auto-merge and auto-push are not settings that ship disabled - there is no code path in Vibestrate that runs git push, and a merge to main is refused unless the request carries your confirmation. The Hard guards on the Policies page name both, and those switches declare the guarantee rather than create it: turning one off does not enable anything, because there is nothing behind it to enable.
That is deliberate. A default can be changed by a config file someone else wrote, by a flag in a CI job, or by a future version that picks a different one. A capability that was never built cannot be turned on by accident, and the one action you cannot undo by re-running the pipeline is the one that reached your shared history.
Keep going
- Your first run - where the change came from.
- Task lifecycle - the statuses a run moves through.
- Worktree - the safe copy each run works in.
Next
Why you stay in the loop → - what actually catches a bad change, and why the last call is a human’s.
