On Tue, Jun 21, 2011 at 3:24 PM, KCO <kochin....@gmail.com> wrote:

>  *Already I have a question... do most of you setup a local version of
> Drupal (or whatever it is) running on your desktop with a local
> version of the database as well?

Yes, always, but generally not the same exact environment that the prod
server would have.

> Or do you push up to the server and
> hope that what you built works and if it doesn't you reverse the push
> (my usage of these terms aren't perfect so please excuse me)?*
I use a tool like capistrano to manage deployment.

> And here is where I'm stuck... from a file system perspective I can
> see this working fine... but regardless if I setup a local version of
> my site or just use the remote version for testing my work, what
> happens to the DB when you start working on the feature?  What if work
> for your feature requires some changes to the DB... what if those
> changes affect the master branch?  Do you now create multiple DB for
> each branch?  I think you see where I'm going...

For php projects, I use Doctrine, and am free to fiddle around with the db
all i want.
If you can't use a tool like doctrine, I'd recommend making schema changes
via a set
of scripts and / or version a schema dump that you can load / some sort of
loading. Managing different environments databases becomes much easier if
creating and modifying the db are files under your (and version) control.

> I very stuck here in terms of what best practices are... I know that
> in systems like WP or Drupal where you shouldn't be touching the core
> code/db and should only be creating plug-ins/modules that you may not
> affect the site as a whole when developing your little piece... but
> what happens to the db?  More than likely it won't change either
> but... ???

I have no clue what best practices for Drupal or WP would be. For php, I've
been using Symfony2 with great success, but it might not fit your use case.

> Can anyone shed some light here on this for me please?
In general, for anything that gets deployed to a server, there will be at
a best practice of "don't edit on the server edit on your machine" and "use
deployment tool".

What's appropriate for the DB might vary from project to
project and framework to framework -- but as long as the stuff you change
change the db doesn't *have* to involve using a frontend to the database by
you can stick the commands you'd run in a script and run that instead --
tools exist
that will do that for you already though, generally called "migrations" and
"data fixtures".
i wouldn't recommend hand-writing those tools unless you absolutely have to.

As long as the commands that change the db are under vc, there are no issues
other than
possibly regenerating dbs when you switch branches -- personally, I create
many, many
branches and the vast majority of them do not require me to change anything
in the db schema.

The ones that do are easy to handle thanks to git and the magic of

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to