Last updated August 24, 2015.
This page documents a high-level overview of the current best practice recommendations for contributing change requests, in the form of a patch file, to projects (e.g., modules, themes, Drupal core, etc) hosted on Drupal.org using Git. For a more advanced workflow with Git, please refer to the Advanced patch contributor guide. Drush issue queue commands makes it easier and faster to create and work with patches.
Note 1: If you're unfamiliar with patching Drupal, please read the Getting Involved section on Patches.
Note 2: If you choose to create patches with a tool other than Git, be sure to produce a
-p1 patch; the old -p0 format was phased out in 2011
There is a short video on Applying and Creating Patches with Git that covers much of this material as well.
General patch guidelines
Keeping things organized
To help reviewers understand the scope of changes, separate each change type into its own patch. For example, bug fixes, performance enhancements, code style fixes, and whitespace fixes all should be in different patches. Each separate change type (and patch) should be associated with a different issue in the queue on Drupal.org.
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
Quick and simple patch
This section is written to be a step-by-step guide to help someone contribute their first patch.
- Go to the module or theme's page. ex: http://drupal.org/project/colorbox/
- Click "Version Control" under the title. ex: http://drupal.org/project/colorbox/git-instructions
- Select the dev version that you wish to patch/update. This is typically the current Drupal release with the module's version and '-dev' appended. ex: 7.x-1.x-dev. Make patches against the -dev version because it is the latest code. Note that when you're working on the -dev branch with git, you won't actually append '-dev' to the branch name or see '-dev' in the branch name. Just the fact that the branch name ends in '.x' (e.g. 7.x-1.x) means it is a development branch. Any changes since the last release, 7.x-1.2, will already be in the -dev branch.
- Click the show button to make sure the "git clone" command line is correct/updated
- Copy the "git clone --branch .. " command
- Now run the git command to download a revisioned copy of the module or theme. Run the command in the appropriate folder (ex: sites/all/modules or sites/all/themes) and it will be the equivalent of downloading and unpacking the module or theme, but with git revisioning.
- In the module or theme directory, tell git to create a 'branch' of the local version you just downloaded so that you can update/change a separate branch, commit those changes, and still easily generate a patch against a local branch. (If the issue appears at http://drupal.org/node/123456 then the issue number is 123456.)
- Notice the '*', it tells which branch git is using. To use the new branch, tell git to checkout the files from branch 1234-fix-for-header. Note: 'git checkout branchname' replaces all of the revisioned files in the directory with the files from that branch, essentially swapping out one version for another. In our case, the files are the same so there isn't any noticeable change. (To quickly fill in the branchname, start typing and hit 'tab'.)
- Now make the changes you want to the module or theme. You can use git to see about general changes you've made, specific changes you made, add files you created, and commit your work.
- When you're ready to make a patch. Go to the folder of the module or theme. Commit any changes you've made, then use 'git diff 7.x-1.x' to review the changes that will go into the patch.
- When you're ready, create the patch with this command:
- Now go upload the patch! congratulations on helping to make Drupal better!
git clone --branch 7.x-1.x http://git.drupal.org/project/colorbox.git
git branch [issue-number]-[issue-description]
ex: git branch 1234-fix-for-header
To see if it worked:
git checkout 1234-fix-for-header
git add new_file.php
git commit -a
git diff 7.x-1.x
(To exit git diff, simply press q.)
git diff 7.x-1.x > [project_name]-[short-description]-[issue-number]-[comment-number]-[drupal-version].patch
- The [comment-number] in the patch filename refers to the comment number, not the comment ID. A good way to guess is to add 1 to the last comment on the issue. More information in the Advanced patch contributor guide.
- The command 'git clone' will only work if the folder does NOT exist. If it does exist it will give you an error. This saves from overwriting any work you might have already done. Either move folder if it already exists, or delete if you have not made any changes.
- If you rename/move the folder, be sure to move it out of of the Drupal directory so Drupal will not detect it as a module or theme and try to load it twice.
- Or, you can run this command in a non Drupal directory, and then copy files you've already edited into the new folder. This has the drawback of not being to able see live changes.
- If your branch doesn't yet work, and you'd like to revert the module to a working/official copy. Commit your changes, checkout the main branch, and then clear Drupal's caches. Note: If you haven't committed your changes yet, git will NOT allow you to change branches.
git commit -a
git checkout 7.x-1.x-dev
More git commands
Be sure you have checked out the branch you wish to patch with the following command.
Ensure it is up-to-date with the following:
git pull origin [branchname]
Make your changes. Then if, for example, the issue appears on Drupal.org at
git diff > [project_name]-[short-description]-[issue-number]-[comment-number]-[drupal-version].patch
[project_name] refers to the project's name as it appears in the URL, i.e.
http://drupal.org/project/[project_name], or from the git remote repository location, i.e.
If you added new files with your patch, then:
git add [path.to.new.file]
git diff --staged > [project_name]-[short-description]-[issue-number]-[comment-number]-[drupal-version].patch
To perform both at the same time:
git add [path.to.new.file]
git diff HEAD > [project_name]-[short-description]-[issue-number]-[comment-number]-[drupal-version].patch
To create a patch of the commits on the current branch that are not on master:
git format-patch master --stdout > [project_name]-[short-description]-[issue-number]-[comment-number]-[drupal-version].patch
Create a New patch
Here is the instruction with the help of we can create a new patch
Firstly write the code in the specific file
and then use this command
git diff > [project_name]-[short-description]-[issue-number]-[comment-number].patch
git diff > abc-make_table-4568951-5.patch
see the e.g
_ (Underscore sign is used to separate the word)
abc is project_name.
make_table is short-description for the issue.
4568951 is issue number. If you issue is https://www.drupal.org/node/1245218 then you can pick the last seven digits of this issue and pick the last comment of this issue.
5 is comment number.
Applying a patch
Download the patch to the root of your working directory. Apply the patch with the following command. The -v flag makes the output verbose so you can see the patch apply successfully.
git apply -v [patch-name.patch]
To avoid accidentally including the patch file in future commits, remove it:
When you're done: Reverting uncommitted changes
Revert changes to a specific file:
git checkout [filename]
Revert changes to the whole working tree:
git reset --hard
Remove files added outside the working tree:
Note: Use with care! Add -n to do a dry run
git clean -fd