Symphony.

I am wrapping my head around GIT, and I was wondering if the following could be achieved by GIT, or what would be the best approach to do this:

I want to create a 'Symphony Template' from which the sites we create at our company will be based on. This template is the same as the default Symphony installer, except with some other extensions than the default ones and some basic file structure and templates in the workspace folder.

The whole idea is that:

• Each new site we are going to create would be a spawned from this template.
• If Symphony upgrades to a newer version, we upgrade our Symphony Template. Next, we can update our sites individualy so they also get updated to the newer template version.
• The same goes for extensions: no more downloading and overwriting, but simply pull the newest version to our template (or site), so they get updated.

Now I am looking deeper into Git and cloning and submodules and stuff, but I can imagine that I'm not the first one who is trying to setup something like this.

Does anyone have any pointers for me to show me the best way to do this?

I've been thinking of doing something similar.

Firstly, this article is very helpful.

Maybe:

1. Clone the Symphony repo
2. Create a new branch for your starting point and check it out
3. Install and initial basic configuration
4. Do your extension/submodule/config/workspace stuff
5. Commit these changes to your starting point branch
6. Clone this repo and use the starting point branch whenever you start a new project (and pull from it to your projects when you make updates to the starting point if you wish)
7. When updating your starting point to a new version of Symphony, checkout the Symphony branch and pull from the Symphony repo, and then checkout your starting point branch and merge from the Symphony branch.

Note that I am new to Git, so don't take the above too literally/seriously, but read that article and see what more experienced users have to say before commtting to anyting. :-)

Nils mentioned something like this at the Symposium, that each site he works on has separate repositories for Symphony, extensions and its workspace. I can't quite remember how he described it, so hopefully he can quickly outline it here sometime.

Have you considered git submodules?

Yes, I use submodules for extensions.

I currently also have the workspace as a submodule from a 'workspace template'-repository. But I couldn't call it workspace because that name was already taken (and put in the .gitignore-file), so I called it workspace.template.

I am think if it wouldn't be better to have the master-branch of Symphony as a submodule in my repository. Is that a better workflow?

I am too still figuring out the best Git Workflow but I believe Nils Werner (@Phogue) probably has been thinking about it the longest ;)

Just to mention some of my experiences (and take-aways from Nils' talk). Please correct me where I'm wrong guys!

• Git is awesome, use it for everything (read: this is probably the way to go, over e.g. Ensembles)
• Git Submodules are hard (but use them anyway :) )
• Use submodules for all extensions (and ignore/uninstall the default ones)
• Set up 1 'remote' as your 'server-repo' for Symphony. Call it 'official' or 'symphony' or something. Use this to pull from to update Symphony
• Before upgrading Symphony, switch to a different Branch and, when done, merge that with your master.
• Set up another 'remote' to push to. This allows you to pull from various machines (and e.g. deply a site by, on the webserver, simply pulling).

So: I would not use a Symphony submodule but pull from a Symphony 'remote' instead. I would also not setup my local workspace as a submodule but just contain that in my local project. You would, of course, have to make sure the workspace does not get overwritten when pulling from the 'official' Symphony.

So, the challenge would be to be able to set the 'official' Symphony Repo as a remote and then pull without overwriting workspace/ and extensions/

You can, by the way, easily change your .gitignore file (to e.g. remove/add the workspace folder).

Again: there have been some excellent threads re: Git on this forum and my guess is that @phoque will soon write another good tutorial.

As with Symphony there are many different ways to handle this and a lot depends on personal preference and workflow.

I think the biggest eye-opener for me was that you can actually switch branches/tags in submodules. I was a bit afraid that adding a submodule, and running update, would keep the extension in it's detached from HEAD state.

But you can go into the [symphony-dir]/extensions/[name] folder and do git checkout [branch/tag]

…which is logical when you understand that the submodule is a complete Git repo (with history/branches etc) right?

I don't completely understand the concept of the 'detached HEAD' though. I ran into it when trying to update submodules. I had to git checkout master before I could do a git pull…

I'm writing a Symphony installation script in bash. It should be the biz. You can pass it a list of extensions with it's invocation and it will do all the work for you.

@designermonkey mmmmm bash script! Sounds ace.

Sounds hard! Wait, it is!

Nils mentioned something like this at the Symposium, that each site he works on has separate repositories for Symphony, extensions and its workspace. I can't quite remember how he described it, so hopefully he can quickly outline it here sometime.

We basically have three default repositories:

• A fork of the main Symphony repository where we removed the extensions that are attached as submodules by default.
• A separate repository where we add the needed extensions as submodules. This repository is added as a submodule to our main Symphony fork. We use branches for different default sets of extensions and – if needed – we create extra branches for more complex projects with special requirements.
• Finally, we have a separate repository containing the workspace folder, that we add to the main folder directly (not as submodule). This folder contains everything we normally need:
  • an assets folder with default styles and scripts
  • default templates (like master.xsl containing the basic HTML structure of a site + kit)
  • all needed Symphony related folders plus a media folder for documents and images uploaded by the users

So when we start working on a site, we normally create a folder with the name of the project and add a clone of our basic workspace in there. So when we built http://symphony-cms.de that was /symphony-cms.de/workspace/. We start with static wire-framing inside our assets folder, first an initial layout in Photoshop and then – as soon as type or responsive elements come in – we switch to HTML, CSS and JavaScript using plain html files named after the different sections of the site we are working on (index.htm, about.htm etc.).

As soon as we are done with the layout we clone our Symphony install into the main folder as well, choosing the needed branch from the extension's repository. We are using Gity to handle all the submodule management (I'm not a command line guy and Gity offers one click actions for the most important actions).

The main reason for this setup was to have a version controlled layout process and to have the ability to share our design via Github as well. In case we need to update the main repo, we create a separate branch in our main fork, merge in the changes. We always have to solve a merging conflict due to our special extension setup but it's just a short unstaging of the default extensions bundled with the core. We then merge that branch into our main one and are able to update all our installs based onto that fork.

Besides the version controlled layout process, we really enjoy Github's issue tracker in this context: we use it to track design changes and design ideas, referencing related issue ids in commit messages of layout additions so they get shown inside the respective issue.

Actually, we are "misusing" a programming tool to organize our design workflow.