Triangular Git Workflows and GitHub CLI Support

Triangular workflows let a feature branch pull updates from one remote reference while pushing to another, reducing repetitive rebase or merge steps. Recent updates to the GitHub CLI align its Git behavior with these configurations, enabling pull request commands to work intuitively across forks and upstream repositories.

Understanding Triangular Workflows

A triangular workflow differs from the classic centralized model by decoupling the branch’s pullRef (the source of incoming changes) from its pushRef (the destination for outgoing commits). This arrangement is common when developers keep a feature branch up‑to‑date with an upstream default branch while pushing their work to a personal fork. The result is a “triangle” of three refs: local, upstream pull, and fork push.

Configuring Push and Pull References

Git determines a branch’s pull reference from the remote and merge keys in .git/config. To point the branch at a different upstream for pulls, change the merge value to the desired remote branch, e.g., merge = refs/heads/main. The push reference defaults to the same remote, but can be overridden with pushremote or the repository‑wide remote.pushDefault setting.

Using the @{push} Revision Syntax

The @{push} syntax provides a quick way to reveal a branch’s push destination. Running git rev-parse --abbrev-ref @{push} returns a human‑readable ref like origin/feature‑x. This mechanism underlies the GitHub CLI’s new logic: it first checks @{push}, then falls back to pushremote, and finally to remote.pushDefault if earlier values are absent.

GitHub CLI Integration

Version 2.71.2 of the GitHub CLI expands the gh pr suite to respect the three‑step resolution order. When you invoke gh pr create on a branch configured for a triangular workflow, the CLI automatically assigns the branch’s pushRef as the PR’s headRef and its pullRef as the baseRef. This eliminates manual flag specifications and aligns CLI behavior with native Git operations.