# Development workflow

> How code gets from your machine into a Home Assistant release. The environment, the tools, the checks, and the review process.

Source: https://contributors.home-assistant.io/core/development/

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.

## Write code

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

## Pull requests

- [Development checklist](https://contributors.home-assistant.io/core/development/checklist/): what to check before you commit.
- [Submitting a pull request](https://contributors.home-assistant.io/core/development/submitting/): branches, commits, the template, and scoping your change.
- [After you open a pull request](https://contributors.home-assistant.io/core/development/review-process/): what happens next, and how to speed it up.
- [Keeping your branch up to date](https://contributors.home-assistant.io/core/development/catching-up/): bringing in the latest changes from `dev`.
- [Reviewing pull requests](https://contributors.home-assistant.io/core/development/reviewing/): what to look for when you review someone else's work.
- [Tips and tricks](https://contributors.home-assistant.io/core/development/tips/): smaller things that make your life easier.

## Changing behavior

- [Deprecating](https://contributors.home-assistant.io/core/development/deprecating/): how to remove or change something without breaking people's homes overnight.
- [Versioning](https://contributors.home-assistant.io/core/development/versioning/): how Home Assistant versions are built up.
- [Labs preview features](https://contributors.home-assistant.io/core/development/labs/): ship a feature people can opt into before it becomes standard.

## The short version

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.