Symphony.

Getting Git for Symphony Development is a great help but I am still a little stuck.

I use Git quite a lot but mostly simply to update exisiting libraries such as Symphony in my local dev environment. Needed Extensions are added/updated through git submodules etc.

'Deploying' mostly means FTP'ing the files from my local (Git) folders to a remote site.

I'd like to move beyond that and start using Codebase to host my complete project in a Git repo. I want to use this (remote) Codebase repo as the 'main' repo and would like to be able to work (push to / pull from) with this repo from multiple machines (Home, Work).

The 'Getting Git' article speaks of various ways to approach this, but it seems I need a mix of these.

Adding Symphony to another Git site project makes me a Welterweight This can be done, the article explains, by creating a separate site branch and merging it with Symphony's branch when it updates.

However: I also want to host my complete Git'ted project on Codebase, I now am an aspiring "Middleweight"

Instead of different branches in this approach

"You’ll maintain a link to the official repository for core updates, but change the origin to your own repository."repository."

This is where I get lost. It's probably the remote and origin concepts that are confusing: it seems rather than creating different branches I now need to (locally?) add my (local?) site repo as a remote to the (remote? as in Codebase?) origin?

Halp?…

The next approach ("Heavyweight") speaks of completely separating the workspace from core Symphony files as a submodule but I would think it makes more sense to actually include Symphony as a submodule.

I also think the approach of Rowan (@Buzzomatic) makes sense: He adds/symlinks different manifest folders for different environments. Something that I would probably need to when deploying from Codebase.

Can anyone (preferably with experience with Codebase - I know you're out here…) point me in the right direction? The article, though helpful, does not seem to address my specific situation. My guess is that there are others that would be helped with this workflow. I know some Symphony heroes have asked a similar question not so long ago which makes me feel a lot better about my n00bness :)

I've got a handful of sites on Codebase. I use (almost) exactly the method described in the Welterweight section.

Remotes

First things first, I usually rename my symphony-2 remote from origin to something more descriptive like official or github. This is so I don't accidentally try to push or pull from the official repo by typing 'origin' when I don't mean it.

Then I add my codebase repo as a second remote (git remote add codebase codebase-url). So I usually end up with two remotes, one called codebase and one called github or something.

Branches

Then I set up my branches. I want one branch pointing to the symphony-2 master branch on Github. My other branch will point to the master branch in Codebase.

I normally rename the existing master branch to something like system (to let me know that's the branch for system updates). I use set-upstream to make it point to github/master.

Then I create a new branch called master which is set to track codebase/master.

I then checkout this branch, remove various unneeded files (installer, updater, readme, etc), remove workspace/ from the .gitignore, and add my submodules. I use Rowan's method for handling the manifest, which you've already pointed to.

Development and Deployment

From there, development happens on the master branch (or sometimes on a third branch before being merged back to master), and Symphony updates get pulled into the system branch before trying to merge with the site code. My live site pulls directly from Codebase.

I think that's everything. Hope it's helpful.

Very helpful. The whole origin master and remote thing is a bit confusing still but I'll give it another read (or two) and see if I get it.

Thanks Charles ;-)

"Remotes" are just remote sources of a repository. Sort of like "mirrors" I guess. Origin is the default name for your default remote.

"Branches" are differing lines of work within the same repository's code. Master is the default name for a repository's default branch.

Does that help?

It does (I sorta figured that out). Thanks a lot. I'll work it out and report back :-)

@davidhund: The whole origin master and remote thing is a bit confusing still but I'll give it another read (or two) and see if I get it.

There's a short explanation of remotes in Scott Chacon's Pro Git book, which might help. And a few practical notes on gitref.org.

@bewildergeist thanks, I'll have a read. In another thread I also came across an interesting (though 'advanced') article: "A Succesful Git Branching Model"

A Git workflow is relatively new for many Symphony users, but seems to be the de facto 'standard' so all extra info/reference on a Git workflow is helpful, thanks.

Actually a symphony user should not be required to use Git. He should be able to simply download the Symphony ZIP file, some extensions ZIP files, install everything and be happy.

But if we talk about Symphony developers, Git has indeed become a de facto standard. The core team jumped into Git first, then many of us followed.

I do it similarily to Craig: Remote upstream for the official GitHub repo and origin for my own one on Codebase. And Branches vanilla for pulling in system updates from upstream and master for main development.

I heavily recommend never ever naming a branch the same as a remote for obvious reasons. :-)

I don't use submodules for workspace but for every extension I use. Just make sure that you point to git://github.com-URLs when using your own extensions as submodules. Everyone who doesn't have write-access to that repo can't use git@github.com URLs.

The whole origin master and remote thing is a bit confusing

Absolutely! Just make sure to remember that origin and master are default names for remotes and branches respectively. So for pulling in a different branch from somewhere else you'd simply need to replace them in the usual, every-day-command git pull origin master

For example when I work on Symphony itself I translate it to git pull upstream integration. Easy, right? :-)

Oh and... Most modern unix shells offer tab-completion not just of commands and filenames but also parameters. I almost always type in

git pull o<tab> m<tab>

wich expands to

git pull origin master

The fact that git pull m<tab> o<tab> doesn't expand reminds me that I wasn't doing it right. :-)

so i've been figuring out how to manage my sites through github with pull/push commands, extensions as submodules, and going through the various linked posts here. However, whenever i do a git submodule update, the extensions seem to update correctly, but then the branch that the extension is on resolves to *(no branch). I was reading this tutorial (search for "update") and it seems that this is ok, as long as you don't need to update/patch the submodule yourself. But if you do need to modify the submodule, you then need to git checkout master (or whichever branch, usually master) to do any sort of modifications. I guess my question is, is this ok to not be on a branch and still have the extensions work at the most up-to-date state after doing a git submodule update? Will this affect anything aside from not being able to modify the branch? I just want to make sure this is normal practice so then I don't need to worry about continuously switching my branch back to the master.

I guess my question is, is this ok to not be on a branch and still have the extensions work at the most up-to-date state after doing a git submodule update?

This is not what git submodule update does.

To update an extension to the most recent version you need to change into its directory and git pull origin master there. After that, go back to the superproject and type in git status. You will see the new commit ID that you've just pulled in (and you need to commit it there).

git submodule update simply tries to sync the submodule with the commit ID saved in your superproject. For example when your collegue updates an extension and pushed the change. After that you need to manually tell Git to sync the extensions using submodule update on every machine.

That actually also makes perfect sense as updating each and every submodule in your project could be very dangerous. You can't be sure that all of them are still stable or compatible with your superproject.

And because submodule update doesn't know what that branch-mess in each and every of your submodule means, it safely pulls into (no branch).

thanks, phoque. Then when is it appropriate to use git submodule update? Only on a fresh install? and then every other time I want to update an extension use git pull?

You will see the new commit ID that you've just pulled in (and you need to commit it there).

So i've updated some extension, albeit in the incorrect way, and I am seeing this when i do git status:

modified:   extensions/author_roles (new commits)

Do i just add that folder like a regular git add? Then does that mean i need to NOT put extensions/ in my .gitignore file?

Then when is it appropriate to use git submodule update?

You use git submodule update from the context of the parent project whenever the parent project itself has been updated to point to new commits in its submodules. In other words, if we update the core Symphony extensions, and then update Symphony itself to point to the new versions, you'll need to update Symphony itself, and then run git submodule update. Does that make sense?

You use git pull from within the submodules when you want to update your parent project from your end.

oy...ok, ya, that makes it a little more clear. Still trying to understand this entire git/dev/staging/prod workflow...getting there...slowly =)

Must be the mountain air up there ;)

If somebody adds a submodule to their repository, will there be a conflict when the repository is pulled from the remote repository?

Depends. If you clone the main Symphony repo, and then start adding submodules on your own copy, it appends those to the .gitmodules file. The only time you'll run into conflicts is if we add a new submodule to the official Symphony repo, in which case your first added submodule will conflict with the newly added submodule. All you have to do is open the .gitmodules file and clean that up.

Thanks Craig... this has been a good discussion!