Twitter Updates
-
RT @Dries: Why is Facebook going public? #funny t.co/qhsKRIZm
-
I'm at Park Village (Boise, Idaho) t.co/PhPurmP3
-
@fillmorejd delicious :-)
My Drupal/Git Workflow
Submitted by cweagans on October 14, 2011 - 12:05pm
I've seen a few posts around Drupal.org 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://drupalcode.org/project/drupal.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 6b54665a5921d26d00559644754047420776da4aThis 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 git@github.com:cweagans/testproject.git
And you can push master there as well:
git push origin masterCaveat: 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://drupalcode.org/project/drupal.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!
Comments
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://git.drupal.org/project/drupal.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:
http://drupal.org/project/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][] = "http://drupal.org/files/issues/1174496.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 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 (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 (not verified) says:
You shouldn't need to find the hash for Drupal core: they're all tagged.
git merge 7.8should work just as well.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 (not verified) says:
You can also just run 'git tag' instead of going to the Drupal repository browser.
cweagans says:
Yep! That's actually something that I meant to write about, but sorta ran out of time.
pcambra (not verified) says:
You could also use a rebase workflow (http://randyfay.com/node/91) instead of merge to avoid "merging" messages
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 (not verified) says:
Effectively or efficiently? ;-)
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?
Add new comment