Development workflow

The day-to-day cycle for a ripgrep change.

1. Clone and build

git clone https://github.com/BurntSushi/ripgrep
cd ripgrep
cargo build              # debug build, fast iteration
cargo build --release    # release build, run benchmarks against this

The repo is a Cargo workspace (Cargo.toml lists crates/*). cargo commands at the root affect every member.

2. Branch and code

There are no required branch-name conventions. Make focused commits; the repo's history shows a strong preference for small, well-described commits over squashes.

If your change spans multiple crates (which is common, e.g., a new flag that needs a matcher option and a printer option), update each crate independently and bump the version in each Cargo.toml only when preparing a release. Versions for the library crates are independent of the ripgrep binary's version.

3. Add tests

Most user-visible changes need an integration test. The project's testing convention is to use the harness in tests/util.rs to spawn rg as a subprocess against canned haystacks in tests/data/. See Testing.

For library-only changes, add unit tests in the same file as the code (#[cfg(test)] mod tests { ... }).

4. Run the full check sequence

Before pushing:

cargo fmt --check
cargo clippy --all
cargo test --all
cargo build --release --features pcre2

The PCRE2 build is necessary because the pcre2 feature is gated behind #[cfg(feature = "pcre2")] and CI builds it.

5. Update CHANGELOG.md

Add a bullet under the TBD section at the top, in the form:

* [BUG #1234](https://github.com/BurntSushi/ripgrep/issues/1234):
  One-line description of the fix.

Use BUG, FEATURE, PERF, or MISC as the tag. The CHANGELOG is the authoritative log of changes. The release script consumes it directly.

6. Open a PR

Mention any related issues. If your change touches user-visible behaviour (output, exit codes, defaults), call that out clearly. The maintainer often asks for benchmarks before accepting performance-related changes; see benchsuite/ for the existing benchmark harness.

CI

Every PR runs .github/workflows/ci.yml which:

• Builds and tests on Linux (stable, beta, MSRV), macOS, and Windows.
• Builds with the pcre2 feature.
• Runs cargo fmt --check and cargo clippy.
• Cross-compiles to musl and aarch64.

A red CI block from a flaky test is unusual; expect to retry no more than once before investigating.

Releases

Release-cutting is documented in RELEASE-CHECKLIST.md. The short version: bump version in Cargo.toml (with the #:version marker), update CHANGELOG.md, tag, push, and let .github/workflows/release.yml build artifacts.