The basics

What is a pull request, and what makes one a draft?

Last updated

What a pull request is

A repository's code has one main version, usually a branch called main. To change it safely, you make your change on a copy, called a branch, and then ask for that branch to be merged into main. That request is a pull request.

The pull request is where the change gets checked. It lists every line added and removed, so reviewers can read the change, comment on individual lines, ask for fixes and, when they're happy, approve it. Automated checks such as test runs usually report there too. GitHub's guide to pull requests goes into more depth.

A ticket says what should change. A pull request is the change itself, ready to inspect.

Reading one on GitHub

Every pull request has a title, a description and a set of tabs. Conversation holds the description and discussion. Files changed shows the change itself: removed lines in red, added lines in green.

The Files changed tab: the fix for the discount-code ticket, plus a new test.Recreation of GitHub's pull request diff in its dark theme. Example repository and code.

What makes it a draft

A pull request is either ready for review or a draft. A draft says "this is a proposal, not finished yet". It shows a grey Draft badge, and in place of the Merge button there's a note that the work is in progress. GitHub won't merge a draft, whatever the person clicking has permission to do. The only way forward is for someone to mark it ready first.

A draft pull request. The Draft badge and the "work in progress" box take the place of the Merge button.Recreation of GitHub's pull request page in its dark theme. The description is a shortened example of the one BacklogBeast writes.

From draft to merged

A draft gets to main in three steps, each taken by a person:

  1. Review it. Read the Files changed tab, and fetch the branch to run your tests if you want to see it working.
  2. Mark it ready. Click Ready for review. The draft becomes an ordinary pull request, and your usual review rules and checks apply. GitHub's guide to changing the stage of a pull request shows where the button is.
  3. Merge it. Once it passes review, merge it the way your team always does.

If the change is wrong, close the pull request. Nothing reaches main, and the branch can be deleted.

Pull requests in Linear

Linear doesn't hold code, so pull requests always live on GitHub or a similar host. With Linear's GitHub integration turned on, a pull request that mentions a Linear issue's id (such as ENG-42) in its branch name, title or description is linked to that issue. It then shows on the issue, and the issue's status can move along with it.

A pull request linked to a Linear issue through the GitHub integration.Recreation of Linear's issue view in its dark theme.

What BacklogBeast leaves you

BacklogBeast works from GitHub issues. For each ticket it finishes, it:

  • pushes its own new branch and opens a draft pull request. It checks afterwards that it really is a draft, and switches it back if not.
  • writes "Refs #42" rather than "Closes #42", so merging never closes your ticket for you.
  • comments on the ticket with a link to the draft, and labels it so you can find it.

It never marks a draft ready, never merges and never deploys. Those steps stay with your team. To see why drafts matter when an agent works on its own, read letting an AI agent open pull requests safely. To keep the number of open drafts manageable, read limiting the review queue.