
A web-focused Git workflow - kqr2
http://joemaller.com/2008/11/25/a-web-focused-git-workflow/
======
vog
If "git push" would work properly for non-bare destinations (as it is the case
with e.g. Mercurial and also Darcs), the design could be simplified by merging
"hub" and "prime".

~~~
windsurfer
You can actually add a git hook or two to make pushing work fine for non-bare
destinations - but then you're trashing any local changes.

~~~
vog
That's why I'm calling it a bug in Git. Other tools (Mercurial, Darcs) don't
trash anything.

~~~
windsurfer
Its a few more lines to prevent trashing.

~~~
vog
That's true, but unfortunately, trashing is the default.

Without any hooks, the next "git commit" on the remote system would add a
patch that reverts the uploaded changes. This is very contra-intuitive and
could be the source of big mistakes. It's a really nasty trap if you don't
watch out!

I like more the approach of Marcurial and Darcs where "not trashing" is the
default.

------
diN0bot
if i understand the post correctly, then i'm using github as the hub, with
copies checked out locally and on the web server.

whoa--- how else do people deploy to live sites? i can't imagine not using
version control. or am i missing some nuance of the situation?

~~~
prodigal_erik
"yum install". We write a .spec file for each service we deploy, and when
we're ready to deploy we compile and package the current release branch. That
way the OS package manager knows what's installed where, whether any
dependencies also need to be installed or upgraded, and whether local edits
should be preserved or renamed.

I've never understood how "git pull" is supposed to configure a production
server correctly. What do people do, put /usr/bin and /usr/lib64 and /etc in
git?

~~~
vog
Although it is usually not done with /usr/*, it is quite common to put a
server's /etc under version control. But that's for administrative control,
and is usually completely separate from the web application.

However, it is quite common to use rsync for deployment of everything: system,
application, etc. from test to production, without any version control needed.
This works especially well when using vservers.

