Pull requests into other branches

Open a pull request into a branch other than the default one, change the branch a pull request merges into, and what holds there.

A pull request merges into its base: the repository’s default branch, unless you choose another. A release branch, a long-running feature branch or a branch that collects several changes before they reach main can each take pull requests of their own.

Open a pull request into another branch

Open Pull requests, then New pull request. Or open Compare, choose the branch to merge into as base and yours as compare, then Open a pull request.
Beside into, choose the branch it should merge into.
Give it a title and a description, and open it.

A branch can have one open pull request into each base.

Change the branch it merges into

You need the Write role or higher.

Open the pull request.
Under its title, choose the branch name after into.
Pick the branch it should merge into.

Changing the base is noted in the conversation and is a pull.base_changed event. Whether it is behind, whether it merges cleanly, and its required checks are worked out again against the new base, and a pull request in the merge queue leaves it.

What holds in another branch

A pull request is held to the rules of the branch it merges into: every ruleset, the repository’s and its workspace’s, whose patterns cover that branch. A ruleset that targets release/* holds for pull requests into release/1.x just as one that targets ~DEFAULT_BRANCH holds for those into the default branch.

	Into the default branch	Into another branch
Required checks, approvals, being up to date	As the rules covering it ask	As the rules covering it ask; nothing when none cover it
Merge queue	Joins it, when a rule requires it	Never; it merges directly
Catching up	Merges the default branch in	Merges its base in
Its issue	Closes when it merges	Stays open

Merging still needs the Write role. Under Settings → Rules, What holds for a branch shows every rule that covers a branch.

g1t’s agent and other branches

When you assign an issue to g1t, its pull request merges into the default branch. Change the base on its pull request and g1t works against that branch from then on: it catches up with it, resolves conflicts with it, and its reviewer compares the change with it. @g1t on such a pull request works against its base too.

From the API

base on POST /repos/{owner}/{name}/pulls (pull_request create) opens it into that branch. Leave it out for the default branch.
base on PATCH /repos/{owner}/{name}/pulls/{number} (pull_request update) changes it.
base filters GET /repos/{owner}/{name}/pulls (pull_request list).
A pull request’s base names the branch it merges into.

curl -X PATCH https://api.g1t.sh/repos/acme/web/pulls/14 \
  -H "Authorization: Bearer $G1T_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"base": "release/1.x"}'

Workflows see the base as github.base_ref and pull_request.base.ref, and branches filters on pull_request match it. A base change starts pull_request workflows with the edited activity type.

Dependency updates open their pull requests into an entry’s target-branch.