I set up a Drupal site under git control for development work.

It's parented in a master, bare GIT repo, and as changes are made in my various project-work git clones, and pushed back to the master, a post-update hook immediately pushes the changes to a single live Staging website (http://staging.loc.). Nothing special, works as expected.

I've also drush-aliased the site "@STAGING". On occassion, I want to promote my changes from the Staging site to a production server.

Two relatively straightforward methods come to mind:

(1) At a point in time when the Staging site appears stable, create the Production site as a git checkout from the master repo,

(2) use drush rsync + drush sql-sync from the staging site to the production site.

Both can be made to work. Other than the fact that (2) seems more Drupal-centric/aware by nature -- drush is, after all, a Drupal-specific set of tools -- what are the relative merits of the two approaches?

Is there any particular reason I should consider (1) over (2)?

In either case "Everything" is under at least one instance of revision control ...

4 Answers 4


I have used both techniques. Both can be used to guarantee that the same files that you test on @stage end up on @live. The advantage of rsync is that you do not end up with extra files (e.g. ".git" and associated) on your production server. I tend to rsync to a vps, and use git on a box I own (e.g. intranet sites).

  • Thanks for the point. I was just looking at the exclusion options. That helps keep things clean. Iiuc, I need to specify what to exclude with "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:'," in the .rc file, though I'm not yet sure if I need that in both the source and target alias' specifcations or just one or the other.
    – user6023
    Commented Mar 7, 2012 at 8:06
  • .git should be ignored by default. Run 'drush --simulate rsync [options] @a @b' to see the exact rsync command that Drush will run. Use --include-vcs if you want drush rsync to include .git and other vcs related files. Commented Mar 7, 2012 at 15:28
  • I need to read up in more detail; I didn't realize that .git was excluded. Thanks for the simulate hint too. Re: the OP, I think I'll stick with the 'drush rsync' as it's designed to be a deploy method for drupal & works. git can work of course but Ive now come across enough comments that it's notdesigned for deploy ...
    – user6023
    Commented Mar 7, 2012 at 16:05

The problem with using drush rsync is that if you have multiple people pushing changes to the server.

Your example only shows one person pushing changes.

If you have developer A pushing her changes and then developer B pushing his changes you want git to mop up the conflicts, or make developer B mop up the conflicts.


I actually use both. svn/git and rsync serve two different purposes. svn/git is for source control, rsync and sql-sync is for syncing staging and prod efficiently. drush rsync @staging @prod is very hard to beat in terms of simplicity, and is dreadfully easy to integrate in most any continuous Integration environnment should you want to dive even deeper in code quality craziness/methodologies.


Personally I use Git for version control, deployment and syncing various server codebases and then rsync to move/sync users files (ignored by adding certain paths to the .gitignore file).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.