How to contribute

This section documents how to work in the Redis codebase: branch model, build/test/PR cycle, how to run tests, how to debug a misbehaving instance, and which conventions to follow.

The official high-level contribution policy is in CONTRIBUTING.md. The pages here zoom in on the engineering aspects: practical commands and conventions a contributor needs day to day.

Quick links

• Development workflow — branches, PR process, what reviewers look for.
• Testing — Tcl integration suite, embedded C unit tests, module tests, sentinel/cluster suites.
• Debugging — logs, watchdog, DEBUG command, gdb tricks.
• Patterns and conventions — coding style, error handling, memory rules, command tables.
• Tooling — code generation, CI, validators.

Where to start

1. Read Patterns and conventions first. Redis has a strong, opinionated style. Anything that violates the style will be rejected in review regardless of correctness.
2. Build the binary with make from the repo root. See Getting started.
3. Run ./runtest to see the test harness pass before changing anything.
4. Find the file by command name. SET is in src/t_string.c, LPUSH is in src/t_list.c, XADD is in src/t_stream.c. Server-wide things are in src/server.c. Networking is in src/networking.c. The mapping is by data type or subsystem, not by alphabetical concern.
5. Add the spec in src/commands/*.json if you are adding a new command, then run make commands.def to regenerate the table.
6. Write a Tcl test in tests/unit/... exercising the new behaviour.
7. Open a PR to unstable. Daily CI will run the full matrix, including TLS, cluster, sentinel, ASAN, MSAN, valgrind, FreeBSD, and macOS builds.

Where things go

You want to add...	You edit...
A new command	src/commands/<name>.json (or <group>-<name>.json) + the C function in the appropriate src/t_*.c or src/<subsystem>.c + a Tcl test in tests/unit/.
A new subcommand of an existing command	The same JSON file (subcommand fields nest) and an extra C handler.
A new configuration option	src/config.c table + an entry in redis.conf (and redis-full.conf if applicable).
A new data type	A new src/t_<type>.c, register it in commands.def via JSON, add encoding constants in src/object.h, plus persistence (src/rdb.c) and replication hooks.
A new module API symbol	src/redismodule.h (the public header) and the implementation in src/module.c.
A bug fix in cluster	Likely src/cluster.c, src/cluster_legacy.c, or src/cluster_asm.c.

Reviewer expectations

Pull requests are reviewed against the Redis style: minimal allocations, clear control flow, no needless abstraction. Practical heuristics:

• No goto err cascades unless the surrounding code already uses them. Some files (e.g. src/networking.c, src/cluster.c) consistently use goto cleanup-style flow; others (e.g. src/t_string.c) use early returns. Match the file you are editing.
• No strdup / malloc directly. Use zmalloc(), zcalloc(), zfree(), zstrdup() so the memory is accounted for in INFO memory.
• No hidden allocations in command paths. Anything that could fail or churn memory should be visible at the call site.
• A passing CI run is the bar. Daily CI exercises ~24 build/test variants. New code should not regress any of them.

See Development workflow for the actual mechanics.