integrationAuto-generate release PRs from git-agent's conventional commit history
release-please automates release management by creating release pull requests that contain a computed changelog, version bump, and updated manifest files. It analyses the Conventional Commits in your git history to determine the next version. git-agent generates rigorous, spec-compliant Conventional Commits, so release-please always sees clean, parseable commit data. The result is a fully automated release PR workflow: commit with git-agent, push, and release-please opens or updates a release PR with zero manual intervention.
Benefits
- Fully automated release PRs: commit with git-agent, push, and release-please handles the rest
- Accurate changelog sections: each commit type is parsed into the correct release notes category
- Consistent manifest updates: version files are bumped automatically from structured commit data
- No manual release decisions: release-please determines the version strategy from git-agent's commit classification
Setup steps
- Install git-agent and configure it to generate Conventional Commits for your project
- Add release-please to your GitHub Actions workflow or install the GitHub App
- Configure release-please's release-type to match your project language (node, python, go, etc.)
- Push a conventional commit generated by git-agent and verify release-please creates a release PR
FAQ
How is release-please different from semantic-release?release-please creates a release PR that you review and merge, giving you a manual approval gate. semantic-release publishes directly on push. Both read Conventional Commits. git-agent is compatible with both, so you can choose the workflow that fits your team.
Does release-please require a specific commit format beyond Conventional Commits?No. release-please implements the Conventional Commits standard. git-agent's output complies with this standard, so no additional formatting is needed.
Can I preview the release PR before merging when using git-agent?Yes. release-please creates a pull request rather than publishing directly. You can review the changelog, version bump, and manifest changes before merging. This is the recommended workflow for projects with manual release gates.