My Drupal/Git Workflow

    I've seen a few posts around from people trying to figure out a solid way to use Git to effectively manage their Drupal installation. This is the method that I've been using.

    Initial repository setup

    To start off, open a terminal and run these commands (you can copy/paste if you want):

    git init
    touch README
    git add README
    git commit -a -m "Initial commit"

    Now, we'll set up the Core remote and fetch Core's history:

    git remote add core git:// 
    git fetch core

    Getting the current code

    Since we've pulled in all of Core's history, we just need to merge a given commit into our current branch. To do that, we'll go look at the repository browser for Drupal Core. Right below the shortlog, there's a section titled "tags":


    Find the tag you want to work off of, and click the "commit" link. In this case, I'll be using 7.8.

    This will take you to the commit browser. Copy the commit hash (we'll need it in just a second):


    Go back to your terminal and run this command (replace the commit hash with the one you just copied from Gitweb):

    git merge 6b54665a5921d26d00559644754047420776da4a

    This will merge the 7.8 commit into your current master branch.

    Working on your project

    You can work on your project as you normally would. Add your own remote (if you want):

    git remote add origin 

    And you can push master there as well:

    git push origin master

    Caveat: If another developer clones from your Github repository, and that developer wants to merge core commits, they will have to run the following commands first:

    git remote add core git:// 
    git fetch core

    Upgrading core

    After you've worked on a project for a while, it's inevitable that you'll have to upgrade core. It's super easy (you'll have to have the core remote set up in your repo first):

    git fetch core 
    git merge [new commit hash]

    If anybody has ideas for improvement on this system, I'd love to hear about them in the comments!


    greg.1.anderson's picture

    greg.1.anderson (not verified) says:

    I use:

    drush dl drupal --select --package-handler=git_drupalorg

    If you select, say, 7.5, then drush will run the following git command:

    git clone git:// /destination/folder
    git checkout 7.5

    From here, you can use git merge just as you did above to update to 7.8, or, alternately:

    git checkout 7.8

    Remote repositories can be added as you show above. I tend to not do this, but if you do, you might want to look at dog:

    However, rather than maintain my own cloned repository, I tend to use drush make to track my changes to core and contrib (that I did not write). I patch only to fix bugs; when I need to do that, I submit an issue to the appropriate queue on d.o., and add the patch URL to my makefile. For example:

    projects[drupal][type] = "core"
    projects[drupal][version] = 6.22
    projects[drupal][patch][] = ""

    The same principal applies if I find an important bugfix from someone else that I need on one of my sites before it is accepted into stable; I add it to my makefile. This makes it easier to see by inspection where my site differs from the stable release. The 'hacked' module is also good for this, but a list of issue numbers is more useful than a collection of patches, or even revisioned git branches (IMHO). Of course I check my makefiles in to a git repository.

    cweagans's picture

    cweagans says:

    The difference is this:

    When you do a git clone from the main Drupal repo, all of the branches and stuff are setup the way they are in the Drupal repo. That is, you have a 7.x branch, and 8.x branch, etc.

    With my approach, you still have the history, but you don't have to have a 7.x branch in your repo.

    And I don't like Drush make very much. It's much less work to just commit the module where you want it (or use git submodule, but that's a topic for a different post)

    greg.1.anderson's picture

    greg.1.anderson (not verified) says:

    Oh, I just tried it, and the following also works:

    git merge 7.8

    So, no need to look up commit hashes if you just want to merge-update to a new tagged release.

    Mark Trapp's picture

    Mark Trapp (not verified) says:

    You shouldn't need to find the hash for Drupal core: they're all tagged. git merge 7.8 should work just as well.

    cweagans's picture

    cweagans says:

    Hey, good idea :) There's only been two or three core upgrades I've needed to do using this method, so I hadn't considered that yet. Thanks!

    Peter W's picture

    Peter W (not verified) says:

    You can also just run 'git tag' instead of going to the Drupal repository browser.

    cweagans's picture

    cweagans says:

    Yep! That's actually something that I meant to write about, but sorta ran out of time.

    pcambra's picture

    pcambra (not verified) says:

    You could also use a rebase workflow ( instead of merge to avoid "merging" messages

    cweagans's picture

    cweagans says:

    I don't think rebase would be applicable here. The idea is that you /want/ to have explicit commits in your repository in this case. For instance, the commit message for the merge might be "Update to Drupal 7.8".

    Vacilando's picture

    Vacilando (not verified) says:

    Effectively or efficiently? ;-)

    Steve's picture

    Steve (not verified) says:

    You shouldn't need the -a flag in the initial commit since you've already added the README file.

    Also, doesn't doing it this way give you tbe entire core history? What if you want a clean Git history for your site?

    Andrew's picture

    Andrew (not verified) says:

    This might be a dumb question because I'm not exactly an expert on Git, but would it be possible to fetch just the branch version I'm using, or do I need to fetch the complete remote?

    cweagans's picture

    cweagans says:

    You can just fetch the branch version you're using, but it probably doesn't make much of a difference. I usually go with git fetch core because it's less typing.

    David Corbacho's picture

    David Corbacho (not verified) says:

    I normally git clone drupal. Thanks for the tips.
    Just wondering if you have changed your workflow (The article was written 2 years ago)

    cweagans's picture

    cweagans says:

    I use a variant of this workflow now. Essentially, I do something like this:

    1. git init
    2. git flow init
    3. <enter>
    4. <enter>
    5. <enter>
    6. [... -- just accept the defaults]
    7. git remote add core git://
    8. git fetch core
    9. git merge 7.25

    I use all of the normal Git flow operations for managing releases and things like that, and then to update core, it's another git fetch; git merge 7.26 (or whatever the new version is).

    David Corbacho's picture

    David Corbacho (not verified) says:

    Nice. I've been using git flow for the last year for a project, so I'm used to it. But I never thought about adding drupal git as a remote. Kudos!

    Add new comment

    Filtered HTML

    • Web page addresses and e-mail addresses turn into links automatically.
    • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
    • Lines and paragraphs break automatically.

    Plain text

    • No HTML tags allowed.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Lines and paragraphs break automatically.
    By submitting this form, you accept the Mollom privacy policy.