Each project points at one repository. Its repository settings control how Coroid interacts with your branching model.
Find them under the project's settings.
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.
Working branches
Every task works on its own branch. Branches are created per task and pushed when the work is ready, 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.