VC integrates with GitHub, GitLab, Bitbucket, and Azure DevOps to clone and publish repositories, create pull requests, and review changes. It also has an in-app panel for working with your local Git state directly.
Connect an account
Install Git and the hosting provider’s tools on the machine running your VC server. For a remote environment, install them on the remote machine. Manage GitHub accounts in Settings → Source Control; other providers use the credentials configured on the server.
GitHub
Install GitHub CLI 2.81.0 or newer. In Settings → Source Control, choose
the environment and add a GitHub account. You can import an account already signed in through
gh, enter a personal access token, or sign in through GitHub using a verification code.
For a token, grant access to the repositories and operations you want to use. A successful
connection verifies your identity; individual repositories can still require additional access.
To sign in through gh before importing an account:
gh auth login
You can connect multiple accounts on the same GitHub host. Choose a default for the environment, or select a specific account in Settings → Projects. A project and its worktrees use that selection for VC’s GitHub operations. Clone and publish also let you choose an account. If an explicitly selected account becomes unavailable, reconnect it or choose a replacement.
Credentials belong to the selected environment, so your other devices can use the same accounts
when connected to it. Removing an account from VC does not sign it out of gh. Account selection
applies to VC’s GitHub requests and authenticated Git operations over HTTPS; SSH keys, commit
name/email, and commands run independently by an agent retain their own configuration.
To enable browser sign-in, create a GitHub OAuth App with Enable Device Flow selected, set
VC_GITHUB_OAUTH_CLIENT_ID to its Client ID on the VC server, and restart the server. No client
secret is needed for this flow. Open the verification link on the device you are using, even when
the VC server is remote. Enterprise hosts must support the device flow; token sign-in remains
available.
GitLab
Install GitLab CLI, then sign in:
glab auth login
Bitbucket
Set an access token in the server’s environment:
export VC_BITBUCKET_ACCESS_TOKEN="your-access-token"
Or use an Atlassian account email and API token with read/write access to repositories and pull
requests, plus user read access (read:user:bitbucket):
export VC_BITBUCKET_EMAIL="[email protected]"
export VC_BITBUCKET_API_TOKEN="your-token"
The access token takes precedence if both are configured. Restart the server after changing these variables.
Azure DevOps
Install Azure CLI, add the DevOps extension, and sign in:
az extension add --name azure-devops
az login
Clone or publish a project
Use Add Project in the command palette (Cmd/Ctrl+K) to clone a repository. Choose a hosting
provider or paste a Git URL, then choose where to save it.
For a local Git repository without a remote, Publish Repository creates a hosted repository,
adds it as origin, and pushes your commits. If there are no commits yet, it creates the remote;
make your first commit before pushing.
Browse your GitHub repositories
Open Repositories from the sidebar or the command palette (Cmd/Ctrl+K) to list every
repository your connected GitHub accounts can reach on the selected environment, including ones
you have not cloned. Search by name or description, narrow the list to one account, or include
archived repositories.
A repository that is already a project opens in the Git manager or the pull request list. Clone starts the clone flow with that repository and the account that listed it, so you only choose where to save it. Each account lists up to its 1,000 most recently pushed repositories. The list is kept for a few minutes; refresh it after changing access on GitHub.
Create a pull request
Use a thread’s Git actions to commit, push, and create a pull request. VC can generate commit messages, review titles, and descriptions from your changes.
Choose the writing style and model in Settings → Source Control. Repository conventions uses the project’s instructions and recent commit subjects.
Stage and commit your changes
The Source control panel works with the thread’s workspace directly. Open it from the Git
branch button in the thread header, the command palette (Cmd/Ctrl+K), or Cmd/Ctrl+Shift+G.
The panel lists your changes grouped as Staged, Changes, and Untracked. Click a file to see its diff, and use a row’s actions to stage, unstage, or discard it. Each group can also stage, unstage, or discard everything under it at once, and can be collapsed to keep a long list readable. Discarding is confirmed first, for one file or a whole group: an untracked file is deleted from disk, a staged file is unstaged, and a file that is in the last commit goes back to its committed contents.
A changed image, here or in a commit from history, shows its before and after versions side by side. Images over 1 MB, and other binary files, show only a note that there is no text diff.
Type a message and commit to record exactly what you staged, so you can build a commit up file by file. This is the difference from the Git actions button, which picks the whole set itself — staging everything, or every file you tick in its dialog — and resets whatever you had staged before, so it cannot see a partial selection. Use the panel when you want to split your work across more than one commit.
If a merge, rebase, or cherry-pick is in progress, conflicted files appear at the top with an Abort action. Conflicted rows deliberately offer no stage action, so a partially resolved file is never staged by accident. Resolve conflicts in the editor or with an agent, then stage the resolved files from the thread’s Git actions.
Browse history, branches, and stashes
The panel’s History tab and the full-page Git manager show the commit graph. Open the Git manager from Git at the bottom of the sidebar, the panel’s expand button, or the command palette. Pick a branch or All branches, tick Include remotes to draw remote-tracking branches too, and search by author or commit ID. Select a commit to see its files and their diffs; a merge is shown against the branch it was merged into.
A selected commit can be cherry-picked or reverted onto the current branch. If either one conflicts, VC undoes it and lists the conflicting files, so your checkout is never left half-applied. Its … menu creates a branch or tag at the commit, checks it out with a detached HEAD, or resets the current branch to it: Soft keeps later changes staged, Mixed keeps them unstaged, and Hard deletes them along with any uncommitted work. In the Changes tab, Amend adds what you staged to the last commit, and a typed message replaces its message.
The toolbar pulls, pushes (setting the upstream on a branch’s first push), fetches every remote, creates a branch at the current commit, and stashes your uncommitted changes. Branches lists local and remote branches, tags, worktrees, and stashes. Select one to show its history, and double-click a local branch to check it out. Select a stash to see what it holds and apply, pop, or drop it.
Fetch runs without a credential prompt, so set up Git credentials for your remotes on the server machine first (see Push fails despite a connected account below).
Review and merge
Open Pull requests to review changes and comments, request reviewers, check out a branch, or merge. You can edit review titles and descriptions and your own comments where the host allows it. GitLab calls these merge requests.
GitHub, GitLab, and Azure DevOps support auto-merge while checks are outstanding. GitHub also supports approving waiting fork workflows and opening a revert pull request for a merged change.
For Azure DevOps, use the host website to view diffs or change comments. Bitbucket does not support reopening a declined pull request.
Watch CI and reviews for a thread’s pull request
Open the thread’s own pull request beside the thread and choose Watch in the Summary tab. On mobile, use the thread’s Git overview. The server follows checks and review threads for the commit you track, so the watch keeps working while no client is open.
Watching alone never messages the agent. Turn on Send new findings to the agent automatically to queue one repair turn per batch of new findings, up to 3 per watch by default (1–20). Restarts and new commits do not reset that count. Ask the agent to fix sends the current findings once without using the automatic limit. Repairs keep the thread’s provider, model, and permission mode, wait for a running turn to finish, and wait out approvals, questions, recovery, and snoozes.
The agent edits and runs checks only; you review, commit, and push. A finished repair does not mean CI passed: the watch reports passing only after the pull request’s checks pass at the tracked commit.
Repairs need the checkout at the tracked commit without uncommitted changes; otherwise the watch says why it is waiting. When the pull request moves to a new commit, queued automatic repairs are withdrawn. Update the checkout, then choose Track to follow the new commit. Turning automatic repair off withdraws only the repairs it queued. Archiving a thread stops its watch, and restoring the thread does not restart it.
Review a pull request with a council
A council has several agents review each pull request a thread opens before anything is merged. Turn it on in Settings → Source control → PR council, add up to 5 members, and optionally choose a leader model; otherwise the thread’s own model leads. On mobile, the same controls are under Settings for each environment.
When VC links a new pull request to a thread (the thread shows it as its own pull request, which happens for threads that work on their own branch, such as worktree threads), a Council · PR #N thread starts in the same checkout, with a matching task on the board. Threads in a shared current checkout do not track a branch, so their pull requests do not start a council. Each member reviews the pull request on its own; members are told not to change anything, but they run with the thread’s permissions. The leader weighs the verdicts, fixes what this pull request needs, pushes, and asks for another round, up to 3 rounds.
When the council agrees, the merge request appears in Inbox. Approving merges the pull request only at the commit the request was made for; if someone pushed since, nothing is merged and the leader is asked to review again. Declining sends your note to the leader. Choose Stop thread on the council thread to end it. Turning the setting off starts no new councils and leaves running ones alone.
Troubleshooting
- Not authenticated: run the provider’s login command on the server, then rescan. For Bitbucket, confirm the running server received the environment variables.
- GitHub sign-in cannot be verified: update GitHub CLI to at least 2.81.0.
- Push fails despite a connected account: check the Git remote’s credentials. SSH and HTTPS remotes can require separate setup from the hosting provider’s API access.
- A review cannot load: open it on the host website while resolving connectivity, permissions, or rate limits.