Merge request guidelines
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.
Help improve this page
You can:
- Log in, click Edit, and edit this page
- Log in, click Discuss, update the Page status value, and suggest an improvement
- Log in and create a Documentation issue with your suggestion