Managing changes and syncing

Buildprint works best when you treat it like a local branch workflow: sync, edit, review, validate, and apply.

Recommended loop

Start in the branch workspace and run buildprint sync to pull the latest Bubble snapshot.
Edit the files you need.
Review your work with git status and git diff.
Run buildprint check before you apply.
Commit your changes. buildprint apply expects a clean worktree.
If Bubble changed while you were working, run buildprint sync again and resolve any merge conflicts.
Optionally preview the result with buildprint apply --dry-run, then run buildprint apply.

It fetches the latest Bubble snapshot for the current branch and brings it into your workspace.
If your local branch has no conflicting changes, sync can be a no-op, a fast-forward, or a normal merge.
If there are conflicts, you get ordinary git conflict markers in files. Resolve them, then git add and git commit as you would in any other repo.
Use buildprint sync --no-merge if you want to fetch the latest snapshot first and merge it manually later.

Apply sends your committed local changes back to Bubble.
It refuses to run if the worktree is dirty, because it applies the current committed state.
By default it also runs an internal check gate so obvious issues are caught before anything is sent.
If Bubble rejects the write because the base moved, sync again, resolve the drift, and retry.

Keep commits small and reviewable.
Run buildprint check --all if you want a full workspace pass instead of only changed files.
Use buildprint tree <target> when you need to understand a page or element structure before editing.
After resolving conflicts, rerun checks before you apply.

Was this helpful?