Repository and branch settings

Each project points at one repository. Its repository settings control how Coroid interacts with your branching model.

Find them under the project's settings.

Synced or local only#

The repository mode decides whether Coroid may write to GitHub or GitLab.

• Synced (the default): Coroid pushes each task's branch and opens pull requests against your base branch.
• Local only: Coroid clones and pulls from the repository but never writes to it. No pushes, no branches on the remote, no pull requests, comments, reviews, check runs or webhooks, no merges and no pipeline runs. Branches, commits, reviews, QA and previews all happen inside Coroid.

Choose the mode when you create the project, and change it under the project's settings. A local only project shows Local only next to the repository name.

Local only is the safe way to try Coroid on a real repository. Tasks and plans run all the way to review. Where a pull request would be, the review shows Kept in Coroid and one action, Start syncing. Approving needs a synced project, because approving merges into your base branch; inside a plan, tasks still come together on the plan's branch in Coroid. Coroid's copy of your base branch stays identical to the remote, so nothing reaches it that you have not opened a pull request for.

To look at the work on your own machine, open Clone and export in the repository settings, create an access token, and fetch Coroid's branches from its own git:

git remote add coroid https://coroid@git.coroid.ai/git/<project-id>.git
git fetch coroid

Start syncing switches the project to Synced. From then on new work is pushed and gets pull requests. Work already kept in Coroid stays where it is: open its pull request from its review page (Create pull request for a task, Open pull request for a plan). Switching back to Local only takes effect immediately.

Nothing in local only mode depends on how your token is scoped: Coroid refuses every write to the repository itself, whatever the connection could do. The mode moves with the project's branch settings in settings portability.

Base branch#

Coroid branches from your base branch and opens pull requests back against it. This defaults to the repository's default branch.

Change it if you merge somewhere else — a develop branch, a release train, or a long-lived integration branch. Getting this wrong is the single most common configuration mistake, and it shows up as pull requests targeting a branch nobody reviews.

When the target branch changes#

A plan records the base branch commit it starts from. If the base branch changes before the plan's pull request merges, Coroid holds the merge; see When the base branch moves. This setting chooses what happens next:

• Pause for review (default) — someone looks at the new commits and either accepts them or asks Coroid to merge them in and re-verify.
• Merge and re-verify — Coroid merges the changes into the plan's lane branch and runs the developer, QA and reviewer again without waiting for anyone. This uses agent hours. If the merge or the re-verification fails, the decision comes back to a person.

Either way, nothing merges until the plan has been checked against the current base branch or a person has accepted the difference. The setting is part of the project's branch settings, so it moves with them in settings portability.

Working branches#

Every task works on its own branch. Branches are created per task and pushed when the work is ready (a local only project keeps them in Coroid), so two tasks running at once never share a branch and cannot see each other's work in progress.

Nothing is ever committed directly to your base branch. That is not a setting; it is a property of how Coroid works.

Branch protection#

Your existing branch protection applies unchanged. Coroid opens an ordinary pull request, so required reviews, required status checks and restrictions on who can merge all behave exactly as they do for your team.

If your protection rules require a signed commit or a specific status check that Coroid cannot produce, the pull request will open and then sit unmergeable — that is your rules working, not a Coroid failure.

Cleanup#

Branches for completed work can be cleaned up after their pull request is merged or closed. If you rely on branch names for audit or release tooling, check this before enabling it.

Changing the connection#

If the underlying repository connection changes — a token rotated, an app reinstalled, a repository renamed — the project keeps its identity and history. Re-point it at the new connection rather than creating a new project, so you do not lose context, settings and past work.

Release pipeline settings#

The base branch controls where Coroid opens pull requests. Deployment uses a separate project Release configuration: an environment, its readiness policy, and optionally a GitHub Actions or GitLab pipeline ref and deployment job. The ref must resolve to the release's pinned commit before Coroid requests a run. Configure an environment-scoped callback credential so the pipeline can report its outcome; the repository connection alone does not prove what was deployed. External pipelines can report events without enabling dispatch from Coroid.

Related#

• Connect your code
• Create and configure a project
• Build and test configuration
• Language support and the agent environment
• Releases