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.
Prior to July 2020, if you wanted to fork a project temporarily so that people could collaborate, you could either use an outside site like GitHub or you could create a "sandbox" project on drupal.org. Starting in July 2020, contributors gained the ability to fork projects using issue forks on GitLab.
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.
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:
