Development workflow

The repository uses a three-branch model: dev for ongoing work, release_candidate for stabilisation, and master for tagged releases.

graph LR
    feature[feature branch] -->|PR| dev
    dev -->|fast-forward or merge| release_candidate
    release_candidate -->|merge after RC tag| master
    master -.->|cherry-pick critical fix| dev

Branches

Branch	Purpose	When to PR
dev	Default branch for new work. Receives the bulk of community PRs.	Any feature, refactor, or non-trivial bug fix.
release_candidate	The next release while it stabilises. RC tags (v1.10.0-RC) point here.	Cherry-picked critical fixes during the RC window.
master	Stable; every tag (v1.10.0, v1.10.1) is on this branch.	Hotfixes only.

The .github/workflows/warns_merge_master.yml action will warn if a contributor PRs into master instead of dev.

Setting up a fork

git clone https://github.com/<you>/stable-diffusion-webui.git
cd stable-diffusion-webui
git remote add upstream https://github.com/AUTOMATIC1111/stable-diffusion-webui.git
git fetch upstream
git checkout -b feature/my-change upstream/dev

Run webui.sh (or webui-user.bat) once to populate venv/, repositories/ and a default model. Subsequent runs reuse the venv unless requirements_versions.txt changed.

Iterating

The Gradio app supports hot UI reload without re-loading the model:

1. Click the Reload UI button under Settings → Show all pages, or
2. POST to /sdapi/v1/reload-ui (when running with --api), or
3. Send SIGHUP-style restart by setting shared.state.server_command = "restart".

These trigger the loop in webui.py — shared.demo.close(), run script_callbacks.app_reload_callback(), re-import scripts, rebuild shared.demo via ui.create_ui(). The current checkpoint stays loaded, so iteration time is fast (1–3 s on a warm venv).

For changes to the boot path itself, fully restart the process.

Submitting a PR

1. Make sure your branch is rebased on the latest upstream/dev.
2. Run ruff check . and npm run lint locally; CI will reject otherwise.
3. If the change adds a user-visible feature or fixes a user-reported bug, add an entry under the unreleased header in CHANGELOG.md.
4. Open the PR against dev and fill out the PR template (.github/pull_request_template.md). Link the issue if one exists.
5. Wait for CI: the Tests job (CPU API tests) and the on_pull_request lint job must both pass.
6. AUTOMATIC1111 (and a small set of frequent reviewers) merge PRs once they're green. There is no formal review SLA; non-trivial changes often sit for several days.

Releases

The release process is loosely documented but visible in tag history:

1. dev is merged into release_candidate via a regular commit.
2. An vX.Y.0-RC tag is cut on release_candidate.
3. Bug-fix-only commits land on release_candidate over a 1–3 week stabilisation window.
4. release_candidate is merged into master, the version is bumped, the CHANGELOG.md entry is finalised, and an vX.Y.0 tag is pushed.
5. Patch releases (vX.Y.Z) follow the same RC-then-tag pattern but on much shorter timelines.

Active contributors: AUTOMATIC1111, w-e-w, Aarni Koskela, catboxanon, light-and-ray, missionfloyd, Kohaku-Blueleaf, brkirch.