Sibling Branch Retarget

When you change the target branch on the rules page, GitAuto automatically retargets all open PRs to the new base branch. If the old and new branches are siblings, GitAuto rewrites the PR to produce a clean diff.

Sibling branches are branches that fork from the same parent (e.g. main) at different points in time, rather than one being the ancestor of the other. For example, release/20260401 and release/20260501 are siblings if they both branched off main independently. This is a common pattern for teams that use date-based or versioned release branches.

The Problem

GitHub's "change base branch" API only updates metadata - it doesn't touch the git history. When two release branches are siblings (both forked from the same trunk at different points), changing the base causes the PR diff to explode with hundreds of unrelated files. Git recomputes the merge base against an entirely different branch, and every file that differs between the two release branches appears in the diff.

How GitAuto Handles It

1. Savethe PR's actual file contents from the current branch
2. Change the base branch on GitHub (metadata only)
3. Reset the local branch to the new base via git fetch + git reset
4. Rewrite the saved files onto the new base
5. Commit per file with the correct verb (Add, Update, or Delete) and force push

The result is a clean PR diff showing only the actual changes, regardless of how different the two base branches are.

How to Trigger

1. Change the target branch on the rules page. GitAuto will retarget all open PRs for that repository.
2. Or leave a review comment on a specific PR asking to change its target branch (e.g. "please target release/20260501 instead").

Why Not Merge?

Sibling branches share no common ancestor besides the trunk (e.g. main). When you run git merge from the new base into the PR branch, Git walks back to that distant fork point and pulls in every change from the other release branch. The PR ends up with hundreds of unrelated files in the diff, which is the same problem you started with.

Why Not Rebase?

A human developer would use git rebase --onto, but this has two problems in automation: rebase can hit merge conflicts and halt (requiring manual resolution), and it requires full commit history which is unavailable in shallow clones (--depth 1).

Our save-reset-rewrite approach avoids this entirely. GitAuto PRs typically add new test files or update existing ones, so they rarely touch the same files as the release branch. And even if the PR's version of a file is outdated after retargeting, the tests will fail, and GitAuto automatically catches and fixes that in its normal workflow.