I use @dev - @stage - @live workflow, managed with drush rsync and drush aliases to update code, syncing db down from @live to @dev / @stage to have recent state.

Recently, I am trying to implement very simple git workflow into it, to secure revisioning of my code. I am not git power user, so I can bear only simple workflow for a good clean simple start (as a single dev I can be spared of situations where many devs are merging/resolving etc.)

There is my local machine (@dev), and staging machine (@stage) that are in my local environment (parties that need to review/QA changes have intranet access to staging machine); @live machine is remote one, and code is drush rsynced to it.

Now, My Local @dev and @stage are not exposed to internet, (can push, but one cannot connect to them from outside)

I have choosen to create "central repo" on @stage machine. I followed strategy simmilar to this: http://toroid.org/ams/git-website-howto . There is bare repo and webroot. Then I cloned from that "central repo" to my @dev machine. When I commit and push to origin from @dev, there is post-receive hook that populates webroot of @stage server with new code state. It is then reviewed, QA-ed.

Now, I am thinking about strategies to propagate those changes on live. I was thinking to modifiy post-receive in such manner, that if "dev" branch is pushed from my local @dev to central repo, code is only propagated in webroot of @stage server. But if I push "master" branch, code would be propagated in webroot of @stage server, and drush rsync would be triggered to do syncing from @stage to @live. Remote @live site, in that case, does not need to have git installed.

I guess it could be done this way (I am testing this workflow already), but I am also considering would it be any gain if git repo would live on @live site too; and if answer is yes, how could I implement that safely (@live is already populated with stable state, but has no git(could have if needed)).

I cannot go to remote @live server and clone from central repo (that is on my @stage machine) because @stage is not exposed to internet (it could be in future, as new devs will probably join to work on project, and will need to clone from that, but for now, it needs to stay local). I am searching for way to push from central repo to @live on when master is updated. Maybe same post-receive that updates @stage after master is being pushed from @dev, can trigger pushing to @live (instad rsyncing to @live?). But how I could initialize repo on @live, bearing in mind central repo is not accessible over net ?

As a side question, is git friendly when I decide to change the whole proccess (for example, move my "central repo" on BitBucket or anoter remote site, more devs join in...?

I also noticed that git cloning does not keep any of interesting user:group privileges, and pushing code could propagate that "lost" file permissions, is this of some concern (I am not version controlling files and such, that is in .gitignore) ? Yet agian I could always run some commands to regain those privileges as in http://drupal.org/node/244924 but I am not sure if this is best practice.

I hope that some of this make sense and that someone with good nerves could give me advice or two. I know this is somewhat simmilar with (dis)advantages of staging dev->production using 'drush rsync' vs 'git'? but it differs in some details very important to me.

  • I'm sorry, but this really needs some focus and be broken down into manageable chunks. It's just not a good fit for DA as it is.
    – mpdonadio
    Commented Mar 6, 2013 at 1:22
  • ok ill try to break my elaborate in pieces and focus unresolvable part in it
    – NenadP
    Commented Mar 6, 2013 at 7:06

1 Answer 1


Your question is a bit long, and too subjective. There are many ways to do things, and the answers to your questions are subjective. For better answers, post shorter questions that ask about a single factual item. It's hard to answer "what is the best workflow"-style questions on StackExchange; those are better handled on a discussion board.

Trying to pick out your specific questions: it is not necessary to use git to push to live, especially if you always keep a copy of the deployed code on your staging server. It might be helpful to record the hash tag that you pushed to live somewhere when your script runs. The main advantage to using git on the live site is that you don't need to do this, as you can use 'git log' to find out what is there. If you do use git on the live site, be sure that the .git files are not accessible to the webserver. I prefer to use this setup:


Regarding permissions, see also http://drupal.org/node/990812. Hopefully I'll have this fixed up and committed soon. It has been languishing for a while; it works, but needs some cleanup in the flags, et.al.

  • 1
    Your tips were helpfull even I have commited terrible sin and will punish myself in privacy. Though, writing such elaborate was punishment itself. Tnx anyway. :)
    – NenadP
    Commented Mar 6, 2013 at 7:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.