Merge request guidelines

Scoping changes

To help reviewers understand the scope of changes, separate each change type into its own issue, each with its own merge request. For example, bug fixes, performance enhancements, code style fixes, and whitespace fixes all should be in different issues. Each separate change type should be associated with a different issue in the queue on Drupal.org.

See Issue scope guidelines for Drupal core issues.

Coding standards

Learn and follow the Drupal project's coding standards.

Coding standards checks, and other checks, are done during testing. It is good practice to run core development checks locally before submitting a change.

Testing

Merge requests are more likely to be accepted if they include automated tests. See Write an automated test for an issue.

Line endings and directory separators

Note for Windows users: Use Unix line endings (LF) and directory separators (/). Many text editors can convert line endings, or you can pipe diff output through dos2unix. See Configuring Git for Drupal.

Version

Generally, you should make merge requests against the most recent development version of Drupal core or a contributed module, theme, or distribution. Wherever possible, bugs are fixed in the latest development version first, and then (at the maintainers' discretion) backported to stable branches. Features are almost always only added to the latest development version.