Git

While Git manages versions of Drupal code, the active configuration used during Drupal runtime comes from the database. The configuration API, when used with Drush, allows for exporting the active configuration from the database to the filesystem, so that it can be committed to Git to be migrated between environments, where it is imported into the database to become active configuration in that system.

Since July 2020, it has been possible to fork Drupal projects on Gitlab. That workflow is integrated with Drupal issues and is now the preferred method for collaboration.

When one or more contributors make and review a patch on an issue, and you agree that the patch should be committed to your project, you need to commit the change in a way that gives all of the contributors proper credit. Here are the steps:

The sections on this page (see "On this page" in the sidebar) are each independent, and describe how to deal with situations that you may see as a project maintainer, but that are somewhat uncommon.

Creating an issue fork

An issue fork is a temporary repository for working on source code changes for an issue. It starts out as a copy of the main repository for the project, but it allows all community members to commit and push changes.

From the drupal.org issue page, you create an issue fork by clicking the Create issue fork button below the issue summary:

Creating issue forks and merge requests describes the workflow for collaborators to create merge requests on per-issue forks -- parts of the Using GitLab to Contribute to Drupal pages.