Using git to manage a website(toroid.org) |
Using git to manage a website(toroid.org) |
If you push to your web server, only your public key is exposed if your web server is compromised.
I'd still recommend pushing to a server though.
As for the difference b/w your method and the OPs, he defines it here :
> This is more convenient than defining your workstation as a remote on the server, and running "git pull" by hand or from a cron job, and it doesn't require your workstation to be accessible by ssh.
Sinatra in front, but all your posts are managed by Git and can be Markdown/Textile/HAML (or anything supported by Tilt iirc). Push it to Heroku if you want easy/free hosting.
Takes care of publishing an RSS feed, tags/categorisation, and a bunch of other nifty things beyond just generating a static site.
Example: http://blog.peepcode.com/
(disclaimer: I used to work with Graham who created it, but I genuinely think it's awesome and use it for almost every site I build now)
I see this strategy removes the need for a second repo on the server. Other than removing a layer which would save space and lower the likelihood of errors in general are their significant pros/cons to either method.
but what you want in code and what you want in the DB will vary from page to page and feature to feature so often just manually redo stuff (in dev env and then again in production) because deploying changes by code is more effort then its worth.
clickable: http://www.soultcer.com/
Edit: In case you are interested, the wiki software was written by a friend and is open source: https://github.com/patrikf/ewiki
Checkout Chronicle (http://www.steve.org.uk/Software/chronicle/). I've put up a HN thread (http://news.ycombinator.com/item?id=2186798).
I wanted to teach myself Ruby and I figured this was a great way to maintain a site, as I'm terrible with both SQL and security. Git solves security and DataMapper solves the SQL, and my Ruby lubricates the rest.
My system actually allows for the metadata to be embedded in the main article file, but it ended up being simpler for me to split the files most of the time (the editing app I wrote does this for me, so I mostly forget about it now).
Just a couple of ideas :)
Living on the cloud has never been so easy :-D
Using git would be pretty pointless, unless you're going to be frequently branching and merging against your mp3s or something.
With GIT thats a moot point in the linked article so long as you are using branches for everything and remembering to push them as well, but sometimes I just want to fix something quickly and do so without a branch. I dont care what people say when you start storing a lot of stuff in GIT a branch can take some time to process.
not always, often stuff is stored in the db that we want to work on in dev then deploy to production.
but it would be nice to be able to export a selection of nodes to code and preserve there id's, content and metadata. maybe you'll find a features contrib mod http://drupal.org/taxonomy/term/11478 but i've never heard of one.
If you want to create content on your dev or staging site and push it to production, check out the deploy module: http://drupal.org/project/deploy
Tracking changes to nodes in production is probably best left to Drupal's built in node versioning system. Diff (http://drupal.org/project/diff) is a handy module to track changes between revisions and if you want a little more advanced workflow check out revisioning (http://drupal.org/project/revisioning) and workflow (http://drupal.org/project/workflow). Good luck!
If it is a small amount of content, such as a handful of pages for a brochure site, putting them in a feature might be best.
If it is a site where customers or visitors generate content on the site, then periodically re-initialize your dev and staging environments with copies of the live DB, running it through a script to anonymize all the user info and change passwords and etc.
If you want to create content on your dev and move it live, then doing a full database copy and moving it live, with settings that are particular to live overridden in settings.php, is probably the best way. I advise against this, basically you are re-launching the site for every change.
If you are truely desiring to be able to create content in multiple different places and move it to live, then probably the best thing to do explicitly program and configure for that, by specifying feeds of the content and setting up the different sites to ingest each other's feeds.