Git + Drupal workflow

Question

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]

1. 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?

2. 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?

3. 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 file and commit the whole thing?

Thanks for the help!

Terry

Answer 1

1. 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.

2. 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.

3. 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.

Answer 2

1. 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.
2. 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.
3. 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.