What to know
- The API is generally available for direct, queued and stacked merges.
- Clients submit a request and poll its returned identifier.
- Permission to bypass rules remains a separate authorization.
Submission and completion become separate steps
GitHub announced general availability of its asynchronous merge API on October 1. The service supports direct merges, merge queues and stacked pull requests. Automation submits with PUT and checks status with GET using a returned request identifier. GitHub recommends the new path for programmatic merges and says it is the only merge API supporting stacked pull requests. Rule bypass remains available only where the caller has permission.
This changes the contract a release script needs to handle. A request being accepted does not necessarily mean a pull request is already merged. The automation needs to retain the identifier and inspect the eventual result before starting work that depends on the new commit. That distinction becomes especially useful in busy repositories where a merge can take longer than a single request.
Analysis: A queue needs a visible outcome
Consider a hypothetical release job that requests a merge and immediately tags the branch. If the merge is still pending, the tag could point to the wrong state. Waiting for a terminal result, then checking the resulting revision, connects the action to the intended release. The same reasoning applies when a stack contains dependencies between changes: the order alone is not proof that every step succeeded.
Retries introduce another question. If a client loses its connection after submitting, it needs a way to determine whether the first request already exists or completed. Blindly repeating actions can produce confusion even when the platform prevents an exact duplicate. A robust workflow should preserve request state and make failure understandable to the person responsible for the release. These are integration concerns, not reported defects in GitHub’s implementation.
Practical implications: Treat status as part of the workflow
Teams migrating merge automation can test successful completion, a rejected request, a blocked queue and a lost connection. The release process should have an explicit response to each outcome, with a bounded wait and enough context for an operator to continue. A status identifier is most valuable when it survives beyond the process that initially created it.
Permissions deserve their own review. Faster or more flexible merging does not justify granting a bot wider ability to bypass repository rules. Its authority should match the work it actually performs. GitHub’s announcement establishes the new API’s availability and intended usage. The useful outcome for engineering teams is an automation that can show which request finished, which revision it produced and which required checks stood behind the merge before downstream deployment begins.
Sources & further reading
Factual statements are grounded in the linked material. Interpretation and illustrative examples are Byte Watchr analysis. Vendor claims are identified as claims, rather than independent testing.
The event date records the source announcement or documented operation. The coverage edition groups recent developments and is separate from the publication date. Actual publication is recorded above.
Corrections policy · About this byline
