Using Git for Site Building
So I want to create a new D7 site and I've read http://drupal.org/node/803746 I think I get it. So basically I'm creating a branch for pure Drupal core which I can pull to whenever I want to update Drupal. Say I only want to work from official releases (current 7.8). I checkout the 7.8 tag. Branch that to "mysite" etc. Then I add all my contrib modules and custom modules to the "mysite" branch. Then when 7.9 is released, I pull again from Drupal.org, checkout the 7.9 tag(?) and then merge that with "mysite"? However, (in part, as 7.8 is a way behind head), isn't my Git timeline cluttered with things that are fairly irrelevant to me? I can see that using Git makes it much easier to get the latest version (rather than download zip, unzip, delete, copy etc), but it makes it harder for me to see my (irregular) changes to my custom modules and htaccess etc when they're mixed in with dozens of changes to core? Especially as lots of those changes are already ahead of where I start building my site? Also, if I'm going this route: should I have contrib be handled by Git as well? So I can pull the latest version of Views or Domain Access? If I do that, does the whole thing end up a mess with 40 remote repositories etc? Are there any other suggestions/alternatives/tips for someone who wants to build a site and use Git mainly to keep track of their own changes? Can I make Drupal a submodule? (I'm still not super sure how there work mind)
Hi there DTH, Personally I use drush to pull and update releases [as it does everything for you, including update.php and clear cache and backup old files] and then I use GIT or Mercurial for my actual project SVC as this then lets me track and roll back/fwd to different releases of my particular website. If I want to update modules, I just do it locally on my laptop, commit the code, check everything out to make sure it is still working, update a test.env if client needs to approve and then change the production to point to the latest code with just two commands [HG pull followed by HG update] and voila, beautiful, elegant and streamlined with lots of fall-back and redundancy. Granted I just threw you a curve ball cause you were not asking about this and you want to use GIT to pull Drupal code instead of using Drush and I'm saying to use GIT or HG [or whatever] for your actual project instead of for Drupal... So feel free to ignore me! :-) S. On 2011-10-25 4:38 AM, DTH wrote:
So I want to create a new D7 site and I've read http://drupal.org/node/803746
I think I get it. So basically I'm creating a branch for pure Drupal core which I can pull to whenever I want to update Drupal. Say I only want to work from official releases (current 7.8). I checkout the 7.8 tag. Branch that to "mysite" etc. Then I add all my contrib modules and custom modules to the "mysite" branch. Then when 7.9 is released, I pull again from Drupal.org, checkout the 7.9 tag(?) and then merge that with "mysite"?
However, (in part, as 7.8 is a way behind head), isn't my Git timeline cluttered with things that are fairly irrelevant to me? I can see that using Git makes it much easier to get the latest version (rather than download zip, unzip, delete, copy etc), but it makes it harder for me to see my (irregular) changes to my custom modules and htaccess etc when they're mixed in with dozens of changes to core? Especially as lots of those changes are already ahead of where I start building my site?
Also, if I'm going this route: should I have contrib be handled by Git as well? So I can pull the latest version of Views or Domain Access? If I do that, does the whole thing end up a mess with 40 remote repositories etc?
Are there any other suggestions/alternatives/tips for someone who wants to build a site and use Git mainly to keep track of their own changes? Can I make Drupal a submodule? (I'm still not super sure how there work mind)
On 25/10/11 18:16 +0700, sebastian wrote:
Personally I use drush to pull and update releases [as it does everything for you, including update.php and clear cache and backup old files] and then I use GIT or Mercurial for my actual project SVC as this then lets me track and roll back/fwd to different releases of my particular website.
How do you roll back and fwd the different settings in the database? regards Rolf -- ... And there comes a time when one must take a position that is neither safe, nor politic, nor popular but one must take it because one's conscience tells one that it is right. — Martin Luther King, Jr.
Hi Rolf, For the database I do dumps, which are in my SVC so I can also roll back to an old one and then import. Granted I would still like to improve this part of my process, as it is the only thing which is not automatically being tracked. It's the last manual process, but fortunately because it is dumping into the repository as well, I don't have to rename the exported DB name and I can thus just re-use the same script to dump. I guess theoretically you could batch that with drush even, or before any drush update. If anyone has a better way of getting an snapshot of the DB I'd love to hear it. Best, S. On 2011-10-25 6:38 PM, Rolf Kutz wrote:
On 25/10/11 18:16 +0700, sebastian wrote:
Personally I use drush to pull and update releases [as it does everything for you, including update.php and clear cache and backup old files] and then I use GIT or Mercurial for my actual project SVC as this then lets me track and roll back/fwd to different releases of my particular website.
How do you roll back and fwd the different settings in the database?
regards Rolf
Hi Sebastian, On 25/10/11 19:13 +0700, sebastian wrote:
For the database I do dumps, which are in my SVC so I can also roll back to an old one and then import. Granted I would still like to improve this part of my process, as it is the only thing which is not automatically being tracked. It's the last manual process, but fortunately because it is dumping into the repository as well, I don't have to rename the exported DB name and I can thus just re-use the same script to dump. I guess theoretically you could batch that with drush even, or before any drush update.
For a new site, this is nice, but if you develop for a site with content, this get's complicated, since you don't want to overwrite the content. At least not, when you propagate your new settings and code to the the live version. Any solution for that?
If anyone has a better way of getting an snapshot of the DB I'd love to hear it.
Me too. Have a nice day Rolf -- ... But, conscience asks the question, 'Is it right?' ...
Hi Rolf, Drupal is just a pain when it comes to merging DB changes from local to production. I use Features [incl Strong arm] and some other modules [Block export] to try and have a handle on that; but I'm certainly open to other recommendations. For continually changing websites I've often found that its easier to check what is changing on production [say comments, node_count and new nodes of X type] and to then script those changes into the development environment as a test-merge in a staging environment, and then move the [successfully] merged code to production once the problems are ironed out. There are also DB change recording tools for Drupal, but the problem is you often don't know yet what the "final" state of something is when you are still building it. Or you have to do all your DB changes in code, instead of using the GUI... and never use the GUI at all. When I said that I do DB backups, I meant that as a solution to LOCAL cahnges [like before updating my Drupal release version from D6.20 to D6.22] but if you are instead trying to track changes from DEV to PRODUCTION you clearly have a very different issue that you are trying to address. SVN's don't really play much of a part anymore, unless you are using the SVC to track user files and such... Best, Sebastian. On 2011-10-28 4:41 PM, Rolf Kutz wrote:
Hi Sebastian,
On 25/10/11 19:13 +0700, sebastian wrote:
For the database I do dumps, which are in my SVC so I can also roll back to an old one and then import. Granted I would still like to improve this part of my process, as it is the only thing which is not automatically being tracked. It's the last manual process, but fortunately because it is dumping into the repository as well, I don't have to rename the exported DB name and I can thus just re-use the same script to dump. I guess theoretically you could batch that with drush even, or before any drush update.
For a new site, this is nice, but if you develop for a site with content, this get's complicated, since you don't want to overwrite the content. At least not, when you propagate your new settings and code to the the live version. Any solution for that?
If anyone has a better way of getting an snapshot of the DB I'd love to hear it.
Me too.
Have a nice day Rolf
On Tue, Oct 25, 2011 at 12:38 PM, Rolf Kutz <rk@vzsze.de> wrote:
How do you roll back and fwd the different settings in the database?
I have experienced some success using Features + Data + Ctools bulk export + Strongarm + hook_update_N(). If they are just settings that go through variable_get, Strongarm will help you. I hope you find this useful. -- Odeyemi 'Kayode O. http://www.sinati.com. t: @charyorde
Hello Kayode, On 25/10/11 15:16 +0100, Kayode Odeyemi wrote:
I have experienced some success using Features + Data + Ctools bulk export + Strongarm + hook_update_N().
If they are just settings that go through variable_get, Strongarm will help you.
I hope you find this useful.
Yes, this is very interesting. Thank you. I need some time to test all the above mentioned. regards Rolf -- ... And there comes a time when one must take a position that is neither safe, nor politic, nor popular but one must take it because one's conscience tells one that it is right. — Martin Luther King, Jr.
participants (4)
-
DTH -
Kayode Odeyemi -
Rolf Kutz -
sebastian