Development workflow

Branch model

There are two long-lived branches a contributor cares about:

Branch	Role
unstable	The main development branch. All PRs land here. It's the source of truth for what will go into the next release.
<x.y> (e.g. 7.4, 8.0)	Stabilisation/maintenance branches for released versions. Bug fixes land on unstable first, then are cherry-picked back.

Releases are cut by the maintainers from a stabilisation branch using the scripts under utils/releasetools/ and the workflow .github/workflows/post-release-automation.yml.

The PR cycle

graph LR
    Fork[Fork redis/redis] --> Branch[git checkout -b feature/...]
    Branch --> Code[Edit src/, src/commands/, tests/]
    Code --> Build[make && make test]
    Build --> PR[Open PR against unstable]
    PR --> CI[GitHub Actions: ci.yml + daily.yml subset]
    CI --> Review[Maintainer review]
    Review --> Merge[Squash & merge into unstable]
    Merge --> Cherry[Optional cherry-pick to maintenance branch]

CI lanes

.github/workflows/ci.yml is the per-PR gate. It runs:

• make on Ubuntu LTS with the default allocator.
• The Tcl unit suite via ./runtest.
• The module API tests via ./runtest-moduleapi.
• A clang-tidy run.
• The reply-schemas linter.

.github/workflows/daily.yml (≈66 KB of YAML) is the matrix run nightly. It exercises:

• Multiple OSes (Ubuntu 20.04/22.04/24.04, macOS, FreeBSD via cross-build).
• Multiple compilers (gcc, clang).
• Optimisations (debug, O0, O3, ASAN, MSAN, UBSAN, valgrind).
• 32-bit and 64-bit builds.
• Cluster, sentinel, TLS, IO threads, and reply-log validation runs.

A PR that breaks daily CI will be reverted; the maintainers do not block merges on the daily lane (CI is enough for green-lighting), but a daily failure in the merge commit triggers an immediate fix-or-revert.

Coding style essentials

Detailed in patterns and conventions. The headline rules:

• 8-space indents, no tabs in new code. Older files have tabs; preserve what is there.
• Braces on the same line (K&R-style).
• /* C-style comments */ only. No // line comments.
• Underscore_lower for variables, camelCase for functions, UPPER_SNAKE for macros.
• Functions are usually < 100 lines. If you need more, the right answer is more functions, not more nesting.

Adding a command

Six concrete steps:

1. Create or edit src/commands/<name>.json. Use a sibling file as a template; the JSON Schema is documented at the top of each file via field names.
2. Run make -C src commands.def. This invokes utils/generate-command-code.py to regenerate src/commands.def.
3. Implement the command function (e.g. myCommand(client *c)) in the relevant src/t_*.c or src/<area>.c.
4. Make sure the function is referenced in src/commands.def (the regeneration step does this automatically based on the JSON's function field).
5. Add a unit test under tests/unit/. Use the closest existing file as a template.
6. Run ./runtest --single unit/<file> to verify. Then run the full ./runtest before pushing.

Adding a configuration option

1. Add a row to the configs[] table in src/config.c (see the existing entries — the table maps option name to type, default, parser, validator, and apply callback).
2. Document the option in redis.conf (and redis-full.conf if applicable) with a comment explaining defaults and trade-offs.
3. Add a test that runs CONFIG SET / CONFIG GET against the new option.

Cherry-picking

When a maintainer accepts a fix in unstable, they decide whether it qualifies for cherry-pick. The mechanics:

git checkout 8.0
git cherry-pick -x <commit>
git push

The -x flag preserves the original commit hash in the message so the relationship is traceable. Cherry-picked fixes are gathered into the next patch release.

Commit message conventions

The repository does not follow Conventional Commits. The convention is:

• One-line summary, ≤72 chars, capitalised, no trailing period.
• Optional body explaining why.
• Reference issue/PR numbers via Fixes #1234 / Refs #1234.

Examples from recent history:

Optimize hash field TTL by avoiding unnecessary lookups in HEXPIRE Fix replication backlog memory accounting after CONFIG SET Add CLUSTER SYNCSLOTS sub-command for online slot resync

Releases and tags

Tagging produces an annotated tag like 8.0.0 plus signed binaries built by .github/workflows/post-release-automation.yml. Release notes live in 00-RELEASENOTES (single file, prepended at each release).