Development workflow

Every change to Home Assistant Core follows the same path. You write code in a development environment, the tests and linters check it, you open a pull request against the dev branch, someone reviews it, and once it is merged, it ships in the first monthly release whose beta is cut from dev after that.

This section covers that path. It applies to everything in core, from a one line fix to a new integration.

• Development environment: the development container, or a manual setup on Linux, macOS, or Windows.
• Code style: formatting, docstrings, logging, and the conventions reviewers look for.
• Type hints: how core uses mypy, and how to opt in to strict checking.
• Running the tests: pytest, coverage, snapshots, and what CI runs.
• Writing tests: how the tests of an integration are organized, with fixtures, mocks, and snapshots.
• Linters, hassfest, and CI: the checks that run on every commit and every pull request.
• Validating input: schemas for config flows, actions, and YAML.

• Development checklist: what to check before you commit.
• Submitting a pull request: branches, commits, the template, and scoping your change.
• After you open a pull request: what happens next, and how to speed it up.
• Keeping your branch up to date: bringing in the latest changes from dev.
• Reviewing pull requests: what to look for when you review someone else's work.
• Tips and tricks: smaller things that make your life easier.

• Deprecating: how to remove or change something without breaking people's homes overnight.
• Versioning: how Home Assistant versions are built up.
• Labs preview features: ship a feature people can opt into before it becomes standard.

If you only remember one thing from this section: keep pull requests small. One fix, one feature, or one refactor per pull request. Small pull requests get reviewed faster, break less, and are easier for everyone, including you.