Branching and Pull Requests: Keep the Main Road Safe
Choose a branching model, use worktrees appropriately, and enforce merge requirements for both human and Copilot changes.
A branch is a temporary road, not another city
A road diversion helps people work without blocking traffic. Leave too many diversions open for months and reconnecting them becomes the hardest part of the project. Branching has the same trade-off: isolation helps, but divergence costs.
Choose a model based on release cadence, supported versions, review requirements, and team capability. A long-lived release branch can be justified for an older supported product; it is unnecessary overhead for a small service deployed many times a day.
| Model | Useful when | Cost to manage |
|---|---|---|
| Trunk-based | Small changes integrate frequently into one main line | Requires fast checks and incomplete-feature control |
| Short-lived feature branches | Changes need isolated review before integration | Large/old branches accumulate merge risk |
| GitHub flow | Branch, PR, review, merge around a deployable default branch | Team must define its release and rollback process |
| Release branches | Different versions need independent stabilization/support | Fixes may need controlled backporting |
| Git flow | Explicit develop/release/hotfix lanes suit a versioned release process | More branches and merge paths |
| Git worktrees | One developer or automation needs simultaneous checkouts | Shared repository metadata still requires care |
Git worktree is a checkout mechanism, not a release strategy. It can support GitHub flow, release branches, or other models. It does not create remote visibility or collaboration merely by existing on a laptop.
Walk through a small, reviewable change
These commands are for a disposable local clone with no unrelated edits:
git status --short
git switch main
git pull --ff-only
git switch -c fix/duplicate-confirmationMake the smallest useful change, run the relevant tests, and commit explicitly selected files. Push the branch and open a draft PR. Include the problem, scope, work-item link, tests, and rollout concerns. Avoid mixing a refactor, dependency update, and bug fix simply because an assistant can generate all three.
For parallel local work, create a different branch in another working directory:
git worktree add ..\booking-hotfix -b hotfix/booking main
git worktree listRun this only in your sandbox and choose a new path. Git normally prevents checking out the same branch in two worktrees. Before removing a worktree, inspect its changes and preserve useful commits remotely; removal is not a substitute for deciding what to keep.
Turn review policy into merge policy
In Azure Repos, configure branch policies on the intended target branch: minimum reviewers, build validation, comment resolution, and linked work-item requirements as appropriate. Decide whether requestors can approve their own changes and whether new commits reset approval. Repository permissions also control direct pushes and policy bypass.
In GitHub, use applicable protected-branch rules or rulesets for required reviews, status checks, code-owner approval, and restrictions on force pushes/deletion. Evaluate bypass actors explicitly. A requirement that administrators can bypass is a different control from one that covers every intended actor.
Do not confuse “a workflow runs” with “its check is required.” Also avoid making a path-filtered workflow the only producer of a required status: if the workflow is skipped, a required check can remain pending and block merging. Design check names and triggering so the required signal is reliably reported.
Test enforcement with a sandbox PR that should fail. A settings screenshot demonstrates configuration, not that the intended actor is actually blocked.
Apply the same boundary to agent-authored code
Copilot can help implement a change, propose tests, or review a PR. These are separate capabilities. Copilot review is not an approving human review and should not be counted as one to satisfy a human approval requirement.
Require the relevant CI results and accountable review on agent-authored PRs too. Do not solve a cloud-agent limitation by granting policy bypass. Verify the base branch, workflow event behavior, permitted actors, and current organization policies for the specific Copilot surface. Product support changes; not every setting in an IDE controls a cloud agent.
Ask an assistant to explain why it chose a merge conflict resolution. A conflict-free merge is not proof of correct combined behavior. Rerun tests after updating the branch, especially when both changes touch assumptions shared across files.
A team uses Git worktrees for two concurrent fixes. Which statement is accurate?
Try it: make the gate fail on purpose
Prerequisites: a sandbox repository where you may configure merge controls, a tiny passing CI workflow, and a second eligible reviewer if testing human review. Some GitHub features depend on repository visibility and plan.
- Create a test branch and PR with a deliberately failing harmless test assertion, not a secret or destructive command.
- Require the exact CI check on the target branch.
- Confirm the merge is blocked. Correct the test and confirm the check changes.
- If testing review policy, verify a non-eligible actor cannot satisfy it.
- Inspect bypass permissions before declaring enforcement complete.
Expected observation: the required check blocks the intended merge path when red. A green check alone still does not satisfy a separate human review requirement.
Cleanup: close the test PR, restore only sandbox policies you changed, and remove disposable branches/worktrees after checking they contain nothing valuable.
Decision check: hotfix or skip the process?
A hotfix path should be a rehearsed, smaller delivery path with defined checks, approval, rollback, and later reconciliation. It should not be an improvised permanent bypass for urgent-looking changes.