git-pr-release: A Release Pull Request That Writes Itself

What the generated pull request is for

git-pr-release creates a release pull request whose body consists of a features list or the pull requests that are to be released into production, and the documentation is explicit that it is especially useful for QA and pre-release checks. That framing tells you the problem it solves. When a release spans dozens of merged pull requests, the list of what went in is the first thing QA asks for and the last thing anyone wants to reconstruct from git log. The tool automatically collects the pull requests merged into the master branch and generates the content of the release pull request, so the notes arrive as a side effect of the merge history rather than as a separate chore. The gem is MIT licensed, published on RubyGems, and the repository is not archived with the last push on 2026-10-20.

The branching strategy it assumes

The tool is designed around a specific branching model, described as similar to git-flow. Feature branches are first merged into a staging or release or development branch, and then the staging branch is merged into the production branch, which is for the production release. That two-stage shape is what gives the tool something to compute. The production branch and the staging branch are the two points it compares, and the difference between them is the set of pull requests that are candidates for the release. If you cut releases straight from main with a tag, or if you squash everything into one branch, the collection step has nothing to work with. The documentation names the production branch as master and the staging branch as staging by default, and both are configurable, so the convention is a starting point rather than a requirement.

The command line options and what each one changes

The usage section is a list of flags, and the interesting ones change what gets collected or what gets written.

git-pr-release
git-pr-release --squashed
git-pr-release --overwrite-description
git-pr-release -n
git-pr-release --no-fetch
git-pr-release --json

The default invocation collects and creates. The --squashed flag includes pull requests containing squashed commits, which matters if your team squashes feature branches before merging, since those pull requests would otherwise be invisible to the collection. The --overwrite-description flag generates a fresh PR description rather than appending to an existing one. The -n or --dry-run flag performs a dry run and does not update the pull request, and the --no-fetch flag skips fetching from the remote repository before determining the target pull requests, which the documentation marks as CI friendly. The --json flag shows the data of the target pull requests in JSON format, which is the way to check the collection before you trust it.

Configuration through git config, and the shared file

All configuration is taken using git config, and the documentation explains an option that is unusual and useful. You can write these variables in a file named .git-pr-release instead of .git/config or ~/.gitconfig, in order to share project-wise configuration with other collaborators. That file sits next to the code, gets committed, and everyone who clones the repository gets the same release process, which is the difference between a convention and a rule. The configuration keys are namespaced under pr-release, so pr-release.token is the GitHub API token and pr-release.branch.production is the branch deployed in production. Every key also has an environment variable equivalent, and they are named systematically, so pr-release.branch.staging maps to GIT_PR_RELEASE_BRANCH_STAGING and pr-release.template maps to GIT_PR_RELEASE_TEMPLATE.

The template, the labels and the mention

The pr-release.template key holds the path, relative to the workdir top, of the template file used for pull requests created. Its first line is used for the PR title and the rest for the body, and it is an ERB template. The default content is embedded in the code and is short: a Release line with the current time, then a loop over the pull requests calling a to_checklist_item method on each. Because the template is a file, the format of your release notes becomes a reviewable artefact. Two more keys shape the output. pr-release.labels is a comma-separated list of labels to add to the pull requests created, with no labels added if it is not specified. pr-release.mention is the name listed next to each PR title, and the only accepted value is author; if it is not specified, the mention is the PR assignee.

Assigning reviewers, and the fallback rule

Two boolean settings decide who ends up on the release pull request. pr-release.assign-pr-author controls whether the related users of the merged pull requests are assigned to the release pull request, accepting true or false, and pr-release.request-pr-author-review controls whether review is requested from those same users. If neither is specified, no assignees are added and no review requests are made. Both follow the same user selection logic as the mention setting, and the documentation states it precisely: if mention is set to author, the PR author will be assigned, otherwise the PR assignee is used, falling back to the author if no assignee exists. That fallback matters in practice, because a pull request with no assignee is common and the choice of who to notify should not depend on it.

The token, the SSL escape hatch and the one failure mode

The pr-release.token key is the token for the GitHub API. If it is not set, you are asked to input a username and password for one time only, and the configuration is then stored, and the same value can be supplied through the GIT_PR_RELEASE_TOKEN environment variable. The pr-release.ssl-no-verify key is the one security setting that reduces safety, and the documentation is candid about why it exists: it might be useful when a self-hosted GitHub Enterprise server is using a self-signed certificate. The value can be set through GIT_PR_RELEASE_SSL_NO_VERIFY to 1, and if it is not specified, SSL certificates are always verified. The single documented error case is no pull requests to be released, which exits with status 1, so a script around it can distinguish an empty release from a successful one.

Editorial conclusion

git-pr-release fits a team with a staging and production branch pair that wants the release pull request opened with the merged work already listed, and that wants the notes format to live in a template file rather than in a wiki page. It is the wrong choice if your releases are cut straight from main with a tag, since there is nothing for it to compare, and the wrong choice if you need the release notes to be written prose rather than a checklist of pull requests. Before you run it in a release, use the dry-run flag and read the generated body, since that is the artefact your team will actually publish.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. x-motemen/git-pr-release on GitHub