Thank you both for your comments... I'm also trying to tackle the same
set of questions on the windows side with another CMS (Kentico) that
my team is managing in addition to WP and Drupal.
I really don't see any easy solution unfortunately.
For the time being we are going to take a slower approach being that
our team is very very new to both GIT and some of the these CMS
systems so rather than creating branches we will stick to one, develop
locally with many commits but no pushes to our central repo until the
project is nearing completion.
Obviously doesn't take into consideration things like patches and such
but we might just create multiple clones for the time being.
Personally I would prefer working with branches but I don't think my
team is ready yet...
Anyway.. I'm burnt for the day and my mind is already reeling .. more
thought for another day.
I'd appreciate anyone else's thoughts on this as well.. thank you!!
On Jun 22, 1:25 pm, ben <bklo...@gmail.com> wrote:
> Hi Ko,
> The DB challenge is a big one with platforms like Drupal and
> For Drupal, you should checkout Features (http://drupal.org/project/
> features &http://drupal.org/node/580026). It allows you to export
> almost everything (views/config/variables) into code, that you can put
> in version control and push to the staging and live servers when
> ready. The only thing it currently don't manage is content (although
> there are some folks working on it).
> As for Wordpress, Jeremiah has the right idea, using custom scripts to
> do migrations is about the only way to keep it in VC. Git does not do
> so well with versioning DB dumps (the repo gets huge very quickly).
> On Jun 21, 12:24 pm, KCO <kochin....@gmail.com> wrote:
> > Hello folks...
> > I was hoping that someone could help me out here. I'm just starting
> > out with GIT and I'm trying to understand how to use branching as best
> > as possible. I understand from the code perspective the benefits of
> > using branching for things like feature releases, version releases,
> > etc...
> > My question is more about what you do with the environment when you
> > branch...
> > So for example, let's say I'm a one man developer (to keep it simple)
> > for a drupal site (or any website with a db really). I do the normal
> > repo setup, clone it on my local desktop and begin happily coding and
> > comitting.
> > *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? 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)?*
> > Ok.. moving on with the idea... now assuming everything is going fine
> > but now I need to build a very complex feature but need to also
> > continue with normal maintenance/patches. So now I create a branch to
> > work on.
> > 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...
> > 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... ???
> > Can anyone shed some light here on this for me please?
> > Thank you!
> > Ko
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 firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at