Symphony.

Hi guys,

I'm just trying to work my way through the git tutorial and I'm running into some problems. Here's what I'm doing, using the Welterweight path:

git clone git://github.com/symphonycms/symphony-2.git site
cd site
git submodule update --init

git branch development
git checkout development
... add extensions
git remote add development ...
... set up git-deploy

At this point, I would now deploy the development branch to my dev server, install symphony, get stuff set up there, commit on the server, then pull the changes on the local branch. Where it starts getting hairy is keeping track of which files to ignore and such, as I'm not entirely sure how the .gitignore file works between branches and remotes. My question to you is, if I plan on pulling updates from the symphony repo, is it safe to edit the .gitignore file to include my workspace after I branch?

Also, if you're deploying on development and production servers using the cloned symphony repo, I'd love to hear your workflow :)

Thanks.

If I remember correctly, you can indeed edit the .gitignore file in your development branch. When you want to update your Symphony installation, you'll checkout the master branch again and then pull, checkout your development branch and merge from master.

I use the same tactic as you: adding the extensions to the development branch (though I name my branch after the project).

I also have the workspace as a submodule ("heavyweight" in the article), which seems to be working out nicely. This means I don't have to worry about the .gitignore file in the main Symphony repository as the defaults (ignoring the workspace) work fine.

DavidOliver: thanks a lot for the feedback! Things are starting to make sense now. On a somewhat related note: if I had a production server set up somewhere, I would just pull from the development server when things are stable?

Yes. If you had updated some of your submoduled extensions, or updated a submoduled workspace directory, you would need to also update the submodules on the production server:

git submodule update --init --recursive

The recursive ensures that submodules containing submodules of their own also have those submodules updated.

This approach works for me because I am usually the only one involved in my website projects, but if you have a team you might like to create a production/stable branch that branches from your development branch, and have this checked out on the production server.