docs: clarify "shared branch" definition in git operations policy - #2306
Michael Flanakin (flanakin) wants to merge 2 commits into
Conversation
Defines shared branches explicitly as main, dev, and features/*, and
carves out personal {username}/{branch} branches from the rebase,
force-push, and history-rewrite prohibitions. A personal branch stays
non-shared regardless of review or comment activity on it, so it can be
synced with dev via rebase instead of only merge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
microsoft-github-policy-service
Bot
added
the
Micro PR 🔬
microsoft-github-policy-service
Bot
added
the
Needs: Review 👀
There was a problem hiding this comment.
🟡 Changes recommended
The updated policy introduces an internal wording contradiction (“all git operations” being non-destructive) that should be qualified to align with the newly permitted history-rewrite actions on personal branches.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Clarifies the repository’s Git Operations Policy by explicitly defining which branches are considered “shared” and documenting when history-rewrite operations are allowed, helping reviewers and contributors apply consistent rules during conflict resolution and branch maintenance.
Changes:
- Defines “shared branches” as
main,dev, andfeatures/*, and clarifies that{username}/{branch}is personal even with review activity. - Updates rebase/force-push guidance to prohibit these on shared branches while permitting them on personal branches.
- Updates conflict-resolution guidance to allow either merge or rebase on personal branches, but only merge on shared branches.
File summaries
| File | Description |
|---|---|
| AGENTS.md | Documents an explicit shared-branch definition and refines rebase/force-push/conflict-resolution rules to distinguish shared vs. personal branches. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
The opening line said "all git operations must be non-destructive," which contradicted the rebase/force-push carve-out for personal branches added earlier in this PR. Also tightens the "shared" definition to mean branches multiple people push to directly, not just a branch with an open, reviewed PR. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Co-Authored-By: copilot-pull-request-reviewer <copilot-pull-request-reviewer@users.noreply.github.com>
|
🤖 [AI][Claude] PR Update Summary Addressed: 1 thread
Reworded the opening "non-destructive" statement to scope it to shared branches, and clarified the shared-branch definition to mean branches multiple people push to directly (not just branches with an open, reviewed PR). 🤖 Generated with Claude Code |
🛠️ Description
Clarifies what counts as a "shared" branch in the repo's Git Operations Policy. Previously "shared branches" was undefined, which came up in PR #2285 when deciding whether rebase/force-push were permitted on a personal
flanakin/*branch that already had review activity.This PR defines shared branches explicitly as
main,dev, andfeatures/*, and clarifies that a personal{username}/{branch}branch is not shared regardless of review or comment activity on it. It also updates the rebase, force-push, and history-rewrite prohibitions and the conflict-resolution guidance to carve out personal branches accordingly — a personal branch can now be rebased ontodev(and force-pushed after) to resolve conflicts, in addition to the existing merge option.📋 Checklist
🔬 How did you test this change?
Docs-only change to
AGENTS.md— no build or deploy impact.📦 Deploy to test?
Not applicable.
🙋♀️ Do any of the following that apply?
📑 Did you update
docs/changelog.md?📖 Did you update documentation?
🤖 Generated with Claude Code