Development workflow

The common path from change idea to merged commit. Authoritative reference: docs/CONTRIBUTE.md and docs/CODE_REVIEW.md.

1. Pick or open an issue

Search existing issues first. If your change is non-trivial, post a message to https://curl.se/mail/list.cgi?list=curl-library or open an issue describing the proposal before writing code. The maintainers regularly mark proposals needs-votes to gauge community interest before approving merges.

2. Branch from master

git clone https://github.com/curl/curl
cd curl
git checkout -b my-fix master

The default branch is master. There are no long-lived feature branches in the upstream repo.

3. Code

Conventions live in Patterns and conventions. The short list:

• C89 compatibility; no C99-only features in lib/ or src/
• Internal symbols use Curl_ prefix; public symbols use curl_ (lowercase) prefix
• Functions used in only one file must be static
• Width: 79 columns, 2-space indentation, K&R brace style
• No tabs in C; tabs in Makefile.am only because Make requires them
• No trailing whitespace, file ends with a newline
• License header at the top of every new source file (see existing files for the template)

Run make checksrc after every batch of edits (scripts/checksrc.pl enforces the rules).

4. Tests

Add a test under tests/data/test<NNNN> that exercises the new behaviour. The test number must be unique; the harness will tell you if it is not. Documentation: docs/runtests.md. For library-internal logic, add a unit test under tests/unit/ (docs/internals/UNITTEST.md describes how).

5. Documentation

If you change a command-line option, edit the corresponding file under docs/cmdline-opts/<option>.md (curldown format). If you change an easy_setopt option, edit docs/libcurl/opts/CURLOPT_*.md. The man pages and --help output are generated from these — make regenerates them via scripts/managen and scripts/cd2nroff.

6. Commit message

subsystem: short imperative summary

Longer explanation of *why* the change is needed. Reference issues
with "Fixes #1234" or "Closes #1234". Mention the testing you did.

Reported-by: Person Name

Common subsystem prefixes: http2:, ftp:, multi:, tls:, cmake:, tests:, docs:. The git log is the project's living changelog — write messages future you will thank you for.

7. Push and open a pull request

git push -u origin my-fix

Then open a PR against curl/curl master. Every PR triggers the GitHub Actions matrices in .github/workflows/ (linux.yml, windows.yml, macos.yml, non-native.yml, http3-linux.yml, distcheck.yml, codeql.yml, checksrc.yml, checkdocs.yml, fuzz.yml, ...).

graph LR
    A[push branch] --> B[GitHub Actions matrix]
    B --> C{CI green?}
    C -- no --> D[fix & force-push]
    D --> B
    C -- yes --> E[reviewer feedback]
    E --> F{addressed?}
    F -- no --> D
    F -- yes --> G[Approved]
    G --> H[Maintainer merges]

8. Review

Reviewers leave comments inline. Address them by amending or appending commits, then force-push (git push -f). It is acceptable, even encouraged, to squash review fixups before the final merge so the history is clean.

A PR that goes 1-2 weeks without contributor response gets closed by maintainers (the contribution rules call this out explicitly). Re-open and re-push when you are ready.

9. Merge

Maintainers merge with rebase or fast-forward — master history is linear. Once merged, your contribution shows up in the next RELEASE-NOTES and the next release on the standard ~8-week cadence (see docs/RELEASE-PROCEDURE.md).

Pre-commit checklist

make checksrc      # style
make              # warnings as errors are encouraged but not enforced
make test         # ~1995 functional tests
( cd docs && make )   # ensures docs still build

For changes to TLS, HTTP/2, HTTP/3, or SSH: build at least once with each backend you have available locally — CI will exercise the rest.