Git Integration

RondoFlow ships with a built-in Git panel so you can review and commit the work your assistants produce without leaving the app. The panel is scoped to a single Workspace’s (Canvas’s) project folder — the working directory — and every operation runs against that one repository.

The panel is a right-side sheet with three tabs (Status, Log, Branches), a repository header showing the current branch and ahead/behind counts, and a footer for committing and pushing. It refreshes automatically and never invokes a shell.

Opening the Git panel

The Git panel is a right-side sheet bound to the active Workspace, keyed by the Workspace ID and its working directory.

Setting the project folder

Each Workspace stores a working directory. When the panel is open it reads that directory and, if it’s empty, lets you point the Workspace at a folder on the host.

Status tab

The Status tab lists every change in the working tree, split into two groups:

• Staged — changes already added to the index. Each row has an unstage action, plus an Unstage All button.
• Changes — unstaged and untracked files. Each row has a stage action, plus a Stage All button.

When there’s nothing to commit, the tab shows “Working tree clean.”

Each file is tagged with a single-letter status badge:

Staging a file calls git add; unstaging calls git restore --staged. After either action the Status view refreshes so the file moves between groups. Status is parsed from git status --porcelain=v2 --branch, so a single file that has both staged and unstaged edits can appear in both groups.

Diffs

You can request the diff for a specific file (or the whole working tree). Diffs come from git diff and are returned as plain text, so you can review exactly what changed before staging or committing.

Log tab

The Log tab shows recent commits — by default the latest 30 (the API accepts a limit from 1 to 200). Each entry shows the commit message, the short hash, the author, and a relative date (“just now”, “2h ago”, “3d ago”, or a short calendar date for older commits). When the repository has no history, it shows “No commits yet.”

Branches tab

The Branches tab lists local branches and marks the current HEAD with a check. From here you can:

• Switch branches — click any non-current branch to check it out (git switch). The current branch is highlighted and not clickable.
• Create a branch — click New Branch, enter a name, and confirm. This creates and switches to the new branch from the current HEAD (git switch -c).

Branch names are validated on both the client and the server against the pattern ^[\w./-]+$. Only letters, numbers, _, /, -, and . are allowed — anything else is rejected before Git runs.

After a switch or create, the panel refreshes Status, Branches, and Log so the view reflects the new HEAD.

Committing and pushing

The footer at the bottom of the panel handles commits and pushes.

How it stays safe

Two guarantees apply to every Git action:

• Workspace resolution, not per-user isolation. Before a command runs, the server resolves the Workspace by ID and returns a 404 (NotFoundError, “Workspace with id … not found”) only if no such Workspace exists. If the Workspace exists, the server uses its workingDirectory regardless of who created it. RondoFlow treats Git as a shared team pool: any authenticated user with a sufficient role may operate on any Workspace’s repository. There is no per-user repository isolation — access is gated by role (below), not by ownership.
• No shell. Git runs through a direct process call (git with an explicit argument array), never shell: true and never execSync. Combined with path and branch-name validation, this prevents shell injection through file names, branch names, or commit messages.

Who can do what (roles)

The Git API is gated by RondoFlow’s default-deny role middleware. None of the Git paths contain a run/execute segment, so the mutating endpoints fall under the write capability rather than run:

In other words, viewers can read the Git panel — Status, Log, Branches, and Diffs — but cannot stage, unstage, commit, create or switch branches, or push. Those mutating actions require the editor (write) role. See Users & Roles for the full capability matrix.

API endpoints

The panel is a thin client over a small Git API. Every endpoint accepts an optional workspaceId (query string for GET, body field for POST) that selects which Workspace’s working directory to operate in; it must be a UUID. Responses use the standard { success, data?, error? } envelope.

Example: stage and commit

# Stage two files in the active Workspace's repo
curl -X POST http://localhost:3001/api/git/stage \
  -H 'Content-Type: application/json' \
  -d '{"paths":["src/app.ts","README.md"],"workspaceId":"<workspace-uuid>"}'
 
# Commit them
curl -X POST http://localhost:3001/api/git/commit \
  -H 'Content-Type: application/json' \
  -d '{"message":"Update app and docs","workspaceId":"<workspace-uuid>"}'

The commit response data looks like:

{ "success": true, "data": { "hash": "a1b2c3d", "message": "Update app and docs" } }

Related