repo-release-tools 0.1.9

Config-driven branch and release helpers for Git repositories

repo-release-tools

repo-release-tools is a small product for conventional branches, changelog policy, version bumps, and opinionated Git workflows across local development, CI, and Copilot workflows.

Product surfaces

• rrt CLI for branch and release commands
• GitHub Action for policy checks in CI
• pre-commit hooks for local enforcement
• Copilot CLI skill for zero-install guidance

Minimal quickstart

pip install repo-release-tools
rrt init
rrt branch new feat "add parser"
rrt git commit "add parser"
rrt git doctor
rrt bump patch

Or:

uvx repo-release-tools branch new feat "add parser"

For basic versioning, bump and ci-version can run without [tool.rrt] by auto-detecting root-level pyproject.toml, package.json, and Cargo.toml. If multiple version files are found they are updated together, and explicit config becomes optional fine-tuning for groups, release branches, changelog paths, lock commands, generated files, or custom patterns. Go repos still need explicit config for file updates because Go has no standard in-file project version. Run rrt init to capture the current recommendation in .rrt.toml.

Minimal config:

[tool.rrt]
release_branch = "release/v{version}"
changelog_file = "CHANGELOG.md"

[[tool.rrt.version_targets]]
path = "pyproject.toml"
kind = "pep621"

Native config is also supported in package.json ("rrt": { ... }) and Cargo.toml ([package.metadata.rrt] / [workspace.metadata.rrt]). Go repos should use .rrt.toml or .config/rrt.toml.

Conventional Branching

repo-release-tools uses conventional branches as the next step after trunk-based publishing. The idea is simple: keep branches short-lived, encode intent in the branch name, and let release automation stay predictable.

The default pattern is type/kebab-case-description, for example feat/add-config-discovery or fix/handle-tag-workflows.

This works well with conventional commits and changelog automation:

• branch type tells reviewers and automation what kind of change is coming
• commit subjects stay conventional for changelog generation
• release branches stay explicit, such as release/v1.2.3

See Conventional branches for the full branch model and supported branch types.

Documentation

• Docs index
• RRT CLI
• GitHub Action
• pre-commit
• Skill
• Conventional branches
• Git magic

License

repo-release-tools is released under the MIT License.

Some workflow ideas were initially inspired by joseluisq/gitnow, but the rrt git surface is intentionally narrower and reshaped around conventional branching, safe commits, and release automation.

Built with ❤️ for safe, simple release automation.