Symphony.

Does anyone use git for local development?

I figured since symphony uses git it would be relatively easy to sync with symphony and its extensions.

However, I’m rather new to git, so I have not yet figured it out completely.

How should I import the symphony code into my local project, and make sure every file (including the workspace and manifest for development) is also pushed into the repo on the webserver.

Any ideas?

I’d be interested to know too. I’m comfortable with Subversion, but Git has never really taken hold for me.

I’m no expert, someone else will be able to speak more authoritatively, just a couple quick thoughts: The main difference between svn and git is that git is distributed. So instead of editing a Working Copy and then running a commit command to send it to the repo, then update through a client at your destination; you’ll commit to your own branch fork, then push to and pull from some other repo. Usually (like in Symphony) this is an origin repo that is acting as the authority for the project. you pull origin to update your fork, and make a pull request for some change you’ve made to the core repo (if that’s what you want).

So working from a local env that has git installed (there is no git client or git server, they’re all basically peers), you would git clone example.com where example.com is the repo url.

Then as far as adding manifest and workspace, I’m pretty sure you just need to remove them from the .gitignore file, then add them to the repo using git add.

At that point you should be able to edit and commit away. Once you’re ready to publish to a produection env, you would just clone your repo on the production server, and either pull into it or push to it from your local dev.

I could be way wrong, but I don’t believe you ‘publish’ a git repo separate from branching forking it, so your production version of your site will be its own git repo as well.

I would love for someone to write a walkthrough for using GIT with Symphony development. Especially if that walkthrough can include Coda (hopefully the next version of Coda will have GIT but right now it doesn’t).

I use Coda and Git for everything I do with Symphony. What did you want to know?

@bauhouse: What would be the best way to incorperate symphony in a local git repo? I could clone symphony, then work from there, or I could add sympony as a submodule to my own repo, and use that.

Is any of these preferred, or should I use something else?

I use Coda and Git for everything I do with Symphony. What did you want to know?

Everything! I literally know nothing about how to make it work. I’d appreciate any tips and tricks right down to a broken down step-by-step workflow.

A Git Workflow for Symphony Development

The theory is that a Symphony install will keep any customizations required to build a site in the workspace directory. In practice, however, there are dependencies on extensions that need to be tracked as well. Also, custom configuration settings in the manifest/config.php file must be tracked. There is also the possibility that custom modifications may be made to the database structure.

A Workspace Repository

If you have a simple site, without extensions dependencies beyond the core extensions, it would be best to keep only the workspace under version control.

cd workspace
git init

That would be how the default Symphony theme works.

The Core Repository

However, most sites have dependencies on other extensions, so you might want to clone the Symphony core, and update the submodules.

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

Then, if you want to maintain a public repository of the ensemble on GitHub, change the remote repositories. You’ll want to maintain a link to the official repository for core updates, but change the origin to your own repository.

git remote add symphony git://github.com/symphony/symphony-2.git
git remote rm origin
git remote add origin git@github.com:username/site.git

Then, when you want to update the core, just pull from the symphony remote.

git pull symphony master

You could also track the integration branch, or any other branch for that matter. To test any differences between the master and integration branches for your install, create another branch called integration and pull from the integration branch of the symphony remote.

git checkout -b integration
git pull symphony integration

Private Git Repositories

If you would rather maintain private repositories, we’re using Indefero to manage the repositories. If you have Git available on your server, you can create a bare repository on your server to use as your remote through SSH. Then you can push your local repository to this remote, and then pull from this remote to your staging or production repository. (See Setting Up a Git Workflow.)

Repository Options

Now, you have a couple options. You can either keep everything in a single repository or create a second repository to track only the changes in the workspace. The workspace repository would be included as a submodule.

Include the Workspace as a Submodule

The benefit of maintaining the workspace as a submodule is the ability to maintain a clean separation between site customizations and the Symphony core. The downside is that you need to maintain two repositories. Lets say that your core repository is called site and your workspace repository is called site-workspace. Here’s the process of setting up the core repository with the workspace repository as a submodule:

Clone the core repository

git clone git://github.com/symphony/symphony-2.git

Rename the repository

mv symphony-2 site

Update the extension submodules

cd site
git submodule update --init

Change the remote repositories

git remote add symphony git://github.com/symphony/symphony-2.git
git remote rm origin
git remote add origin git@github.com:username/site.git

Assuming that you want to start with a clean Symphony install, you would want to install Symphony at this point to create and populate the workspace directory. Once installed, you can initialize the repository for the workspace and set up the remote repository.

cd workspace
git init
git add .
git commit -m "Initialize workspace repository"
git remote add origin git@github.com:username/site-workspace.git
git push origin master

Then, remove the existing workspace and add the workspace as a submodule.

cd ..
rm -rf workspace
git submodule add git@github.com:username/site-workspace.git workspace

Include Extensions as Submodules

I created a tutorial for adding extensions as submodules.

Track Database Changes

To keep track of changes to the database, you can use Nick’s Database Synchroniser extension. I hate to admit it, but I have yet to find the time to try this one out.

Instead, I keep track of changes in the database by using the Export Ensemble extension. However, I don’t want to export the entire site every time I want to update the workspace/install.sql. Plus, there are times when the export fails, because there are too many extensions and PHP hits a memory limit on the server trying to ZIP up all the extensions. I have been able to get around this failing by creating a branch of the Export Ensemble extension that only exports the install.sql file.

cd site/extensions/export_ensemble
git remote add bauhouse git://github.com/bauhouse/export_ensemble.git
git checkout -b sql
git pull bauhouse sql

Then, I can easily switch between the two versions of the extension by checking out the appropriate branch. To export the full ensemble:

git checkout master

To export only the install.sql file:

git checkout sql

Then, every time I make a change or set of changes that I want to track in the repository, I’ll export the ensemble, extract the file from the ZIP archive and copy the workspace/install.sql file into the workspace, overwriting the existing file.

Just be aware that for extensions that make changes to the database, these changes are not tracked by the Export Ensemble extension. For example, the Members extension adds tables to the database which require modifications to the Export Ensemble extension, so I have created another fork of the extension to be able to track these changes, as well as the structural changes.

I would not recommend this process for a team development environment where you have development, staging and production servers that need to be in sync. You’ll definitely want to consider Nick Dunn’s Database Synchroniser extension.

Track Configuration Changes

If there are changes to the manifest configuration settings, you don’t necessarily need to put the config.php file under version control. These changes can be made to the install.php file.

Symphony Ensembles

In the end, if you follow this process of tracking all the changes made to workspace files, install files, extensions, and configuration settings, you will end up with a Symphony Ensemble that can be shared with the community or with coworkers.

Stephen, thanks for your write-up. It’s great (as usual!) and helpful.

Yeah, wow that’s fantastic!

The only thing I’d recommend is that this find it’s way into the official documentation somewhere.

Thanks, Nils.

Doug, I agree. I think that’ll be up to the Documentation Working Group.

Thanks Stephen, you are a hero!

Something I’ve been wanting to figure out for a while is how to cleanly create a local branch that doesn’t share the same commit history as other local branches in a repository. For example, there are some major differences with the many Members extension releases, so pulling local copies of theses branches can be a pain. I finally found a way to minimize that pain. These two commands will fetch the objects for the remote repository and create a new branch that tracks a remote repository branch and switches to that branch independent of the current commit of the currently checked out local branch.

git fetch origin
git checkout --track -b integration origin/integration

To create a new empty branch in a local repository, do the following:

git symbolic-ref HEAD refs/heads/newbranch 
rm .git/index 
git clean -fdx 
<do work> 
git add your files 
git commit -m 'Initial commit'

This might be helpful to add to the new Git documentation.