Git + Drupal workflow_问答_开发者_运维开发者技术经验分享

I'm a Git beginner with workflow questions. I've learned lots of commands, and I know how things work, but I can't seem to figure out the right workflow. Love to have some suggestions. [Note, I'm the only developer working on my projects]

A friend once told me that it was best to work on the live server rather that on localhost to avoid running into environment specific issues. This true?
I use the same base theme for all of my Drupal sites. When I make a change in one, I currently need to copy and paste it to about 10 other places. Is there a way keep this base theme in one place and have other sites draw from it? Github maybe?
If I want to do a 'complete' backup of the codebase and the database - the only way to do this is to export the database as a sql 开发者_如何学Cfile and commit the whole thing?

Thanks for the help!

Terry

In general, you should run testing on a server as close to the production server as possible, but not the actual live server, as that'll break a live site during testing. Because Drupal is designed to run well on a variety of servers, using similar servers isn't as relevant.
You should use git pull instead of copy-paste. Because git has a decentralized designed, you don't really need a central location like github. If that's useful for your workflow, use it, but if not, you can pull directly from one server to another.
There's not a great solution to Drupal storing so much configuration information in the database and keeping that synched. Syncing your entire database is one approach. Many modules also have exportables, which basically save data from the database into code so you can sync it along with the rest of your code. Features is probably the simplest way to experiment with the exportable model and see if that works for you.

I understand your friend's point, but I firmly disagree with running (potentially, err, probably) broken development code on a production server. Better, download VirtualBox and set up a VM with the same configuration as the server you deploy to. Use git to create "tags" for each version you deploy so you have useful reference points for "versions" of your website.
Look at "git submodules". You almost certainly need to learn what these are, but if you've come from a subversion background you'll probably find them very confusing. Submodules are basically references to other repositories, so you have a soft-link to another project inside your main project. They have to be self-contained in a directory however.
I personally like to keep a schema.sql file in my repository (just a blank schema, written in SQL) but I don't think keeping your full database backups in the repository would be a wise thing to do, even though you can. Keep those separate.

If you're new to the whole idea of version control systems, you're probably better off just jumping in with both feet. It will all start to make sense as you go. And of course, by its very nature you're unlikely to do any permanent damage since you can roll back and forth.

One firm recommendation: commit frequently. Every time you make a change that works, commit. Smaller commits are much easier to handle than large ones. For example, if you need to undo a broken change, you're much more likely to be able to undo it without removing a heap of working code that was committed at the same time if your commits are atomic.

for dumping a drupal db regulary i use

a) a git alias for creating an empty, unconnected branch named "db" find the alias at http://gist.github.com/360294

b) the following commands, using the great maatkit tools, to empty some uninteresting tables and dump the db into seperate files, without comments

mk-find DBNAME --tbllike "cache%" --exec "TRUNCATE %D.%N"; 
mk-find DBNAME --tbllike "watchdog" --exec "TRUNCATE %D.%N"; 
git checkout db && \
cd /GITROOT/db && rm -rf * && \
mk-parallel-dump -d DBNAME -- mysqldump --skip-extended-insert --skip-comments --skip-lock-tables '%D' '%N' \> '%N.sql'

In general, the closer your environments are to each other the better. This becomes especially important when trying to diagnose and track down issues. It is not that it isn't possible to have different setups in each of your environments (dev, qa, prod, etc) but I would certainly say it is preferable to be consistent if possible.
Setting up a git repository for a shared theme is a great idea to remove the issues inherint with copying/pasting your changes. Whether you set up a git repository on your own server or using a service like github is strictly a matter of personal preference.
Yes, to get absolutely everything in a backup you need to do a sqldump of the database in addition to having your code repository. That being said, make liberal use of the Features module and get as much of your configuration in code as possible. This also helps when moving between environments as well as being able to track versions of your changes along with the rest of your code. Some of the most important items to add to your features will be content types, views, permissions, variables (via Strongarm), block placement (via Context), menus etc.