Summary
The per-project "Branch prefix override" setting (Project Settings → Branch prefix override, screenshot below) currently only lives in the app's local SQLite state (projects.branch_prefix) and must be set manually, per machine, through the UI. Please add a branch_prefix field to .github/github-app.yml so it can be version-controlled and shared automatically across a team, consistent with how instructions, server_ready_pattern, and auto_open_in_browser already work in that file.
Current behavior
- Project Settings has a working "Branch prefix override" toggle + text field (supports
%username%/similar placeholders, e.g. %dat%- → preview %dat%-my-feature).
- This setting is local-only: it lives in the per-user
~/.copilot/data.db (projects.branch_prefix column) and has to be re-entered by every teammate, on every machine, for every clone of the project.
.github/github-app.yml already supports several per-repo settings that mirror Project Settings fields 1:1 (instructions, server_ready_pattern, auto_open_in_browser, automation.*), but not branch_prefix.
Proposed change
Add an optional branch_prefix field to the github-app.yml schema, e.g.:
branch_prefix: "copilot-"
Behavior should match the existing UI field:
- Supports the same placeholder syntax (e.g.
%username%).
- An explicit empty string (
branch_prefix: "") disables any prefix, matching the existing 3-state semantics already implemented for projects.branch_prefix (NULL = inherit global default, "" = explicitly disabled, non-empty = literal override).
- Since this file already goes through a user trust/approval prompt before any of its settings are applied (per the existing
accept_repo_config/revoke_repo_config flow), this fits naturally into the same trust model — no new security surface needed.
If it conflicts with the local per-project UI override, the more specific/most-recently-set value should probably win, or the UI field could simply be treated as read-only display of the effective value when set via config-as-code (whichever is simplest to reason about).
Why this matters
Related open requests confirm real demand for consistent, shareable branch naming across a team:
None of these solve the "make it consistent for my whole team without everyone manually configuring their own app" problem — which github-app.yml is exactly the right mechanism for, since it's already the config-as-code surface for other per-repo settings.
Additional context
Filed after reverse-engineering the github-app.yml schema for #83 (doc gap) — happy to share findings on the current schema if useful for scoping this.
Summary
The per-project "Branch prefix override" setting (Project Settings → Branch prefix override, screenshot below) currently only lives in the app's local SQLite state (
projects.branch_prefix) and must be set manually, per machine, through the UI. Please add abranch_prefixfield to.github/github-app.ymlso it can be version-controlled and shared automatically across a team, consistent with howinstructions,server_ready_pattern, andauto_open_in_browseralready work in that file.Current behavior
%username%/similar placeholders, e.g.%dat%-→ preview%dat%-my-feature).~/.copilot/data.db(projects.branch_prefixcolumn) and has to be re-entered by every teammate, on every machine, for every clone of the project..github/github-app.ymlalready supports several per-repo settings that mirror Project Settings fields 1:1 (instructions,server_ready_pattern,auto_open_in_browser,automation.*), but notbranch_prefix.Proposed change
Add an optional
branch_prefixfield to thegithub-app.ymlschema, e.g.:Behavior should match the existing UI field:
%username%).branch_prefix: "") disables any prefix, matching the existing 3-state semantics already implemented forprojects.branch_prefix(NULL= inherit global default,""= explicitly disabled, non-empty = literal override).accept_repo_config/revoke_repo_configflow), this fits naturally into the same trust model — no new security surface needed.If it conflicts with the local per-project UI override, the more specific/most-recently-set value should probably win, or the UI field could simply be treated as read-only display of the effective value when set via config-as-code (whichever is simplest to reason about).
Why this matters
Related open requests confirm real demand for consistent, shareable branch naming across a team:
None of these solve the "make it consistent for my whole team without everyone manually configuring their own app" problem — which
github-app.ymlis exactly the right mechanism for, since it's already the config-as-code surface for other per-repo settings.Additional context
Filed after reverse-engineering the
github-app.ymlschema for #83 (doc gap) — happy to share findings on the current schema if useful for scoping this.