Merge request guidelines

Last updated on
26 February 2024

This documentation needs review. See "Help improve this page" in the sidebar.

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 standard checks, and other checks, are done during testing. It is good practice to run core development checks locally before submitting a change.

Testing

Merge request are more likely to be accepted if they include automated tests. See also 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 also 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.

Tags

Help improve this page

Page status: Needs review

You can: