Each project links to one repository. The repository settings determine how Coroid interacts with your branching model.
You can find these settings under the project's settings.
Base branch
Coroid branches from your base branch and opens pull requests back against it. By default, this is the repository's default branch.
Change it if you merge into a different location — a develop branch, a release train, or a long-lived integration branch. Setting this incorrectly is the most common configuration error, leading to pull requests targeting a branch that nobody reviews.
Working branches
Every task uses its own branch. Branches are created per task and pushed once the work is ready, ensuring that multiple tasks running simultaneously never share a branch and cannot view each other's in-progress work.
Nothing is ever committed directly to your base branch. This is not a configurable option; it is a fundamental aspect of how Coroid operates.
Branch protection
Your existing branch protection rules remain unchanged. Coroid simply opens a standard pull request, so required reviews, status checks, and merge restrictions function exactly as they do for your team.
If your protection rules demand a signed commit or a specific status check that Coroid cannot generate, the pull request will open but stay unmergeable — this reflects your rules in action, not a flaw in Coroid.
Cleanup
Branches for completed work can be removed after their pull request is merged or closed. If you use branch names for auditing or release processes, verify this before enabling cleanup.
Changing the connection
If the underlying repository connection changes — such as a rotated token, a reinstalled app, or a renamed repository — the project retains its identity and history. Re-point it to the new connection instead of creating a new project, to avoid losing context, settings, and past work.