Symphony.

What do you mean by “remote repo”?

Remote could be the source on Github as well as your staging- or production-servers… or anything completely different. :-)

Ok, I understand I’m being too simplistic there.

By remote I mean on my live server. I don’t have staging servers. I usually just work directly from a live server, but I understand that if I need to make any changes or any new features come out I would be advised to work locally.

In this case I’d suggest you to have a repo on your server, call it production, and one (or more) locally. Once your local code runs fine you can push it to production.

So basically production is your live site?

In this case, yes. I’ve never had the pleasure to have git on my servers though.

You could also create another repository on a server wich you and your servers push and pull from. In this case, the repository would be similar to the ones hosted on github.

Right, not really worth having 3 repo’s though. I would be best served having a local repo and my live/production repo.

Right, not really worth having 3 repo’s though.

Well… As soon as you have more than one person (or more than one computer) working on your project, you’re going to need them.

Of course, but for my purposes. Out of interest if you wanted to use someone else’s repo, would you pull it and then push it to your live server?

I don’t know what you mean by “use someone else’s repo” but yes, everything should go through yours.

Well be someone else I mean another person.

Yes, of course. But what does “use it” mean? A submodule, a clone, push/pull/merge-collaboration?

Right, well this is where it is beyond my scope of knowledge.

I’m still new to Git, just bought a book on it too…

The way I’m going to set up my repository is based on Stephen Bau’s instructions here. Although slightly different.

I’m initialising the repository, setting up the remotes to Symohony, and my Github repo, the just pulling the master branch from Symphony and merging it, then pushing it to my repo. I’m also going to submodule all the extensions via the Symphony repo, and add all the others I use as submodules too. That way the /workspace folder and /manifest and all the other post-install files will be my unique content, and all the other files can be updated at every release from the Symphony repo using pull.

At least I think that’s the best way to do it, that way I don’t have to use the entire Symphony repo via clone, and have all the history I don’t need.

If I’m doing it wrong, I’m open to suggestions from anyone…

Hi Guys,

I am still struggling with Git and Symphony (Extensions as Git submodules). On my server I do not have Git, so I’ll have to update the files manually anyway, but I’d like to keep my local Git’ted Symphony up to date.

Udating the Extensions works fine: simply cd into the Extensionsextension-dir and git pull. However, now that I need to update Symphony to 2.1.2 I cannot simply git pull the Symphony folder since it is giving me warning regarding the .gitmodules file:

Entry '.gitmodules' would be overwritten by merge. Cannot merge.

So, how do I safely update my Symphony without touching locally modified files (.htaccess, .gitmodules and maybe some core-changes (ouch)?

If you pull Symphony into another branch (leaving your modded one as the master) and then try a merge, what happens?

@designermonkey how would I do this? Would I need to do a new checkout of Symphony ‘next’ to my original one? (yes, as you can see I’m quite new to Git :-( )

To be honest, so am I…

I did it right at the beginning, I’m not sure half way down the line…

@davidhund You’re not alone, I’m literally in the process of writing the Git guide for Symphony and I ran into this same problem myself last night!

I got around this by making a backup copy of the .gitmodules file, then removing it with git rm .gitmodules and doing a commit. Then git pull worked and I could add the modules file back later. But, I have no idea if this screwed me for future updates.

The merge conflicts will be unavoidable if you’re editing core files and changing submodules. They key, I think, is to split git pull into its constituent parts—fetch and merge—so that Git marks up your merge conflicts and allows you to resolve them. If all you’ve changed is the .gitmodules file, you shouldn’t have much of a problem sorting it out. Git tells you exactly what files require attention, and marks them up so you can see both versions.

Anyway, here’s the simple solution, assuming the official Symphony repo is your origin and you’ve only got a single master branch:

git fetch origin
git merge origin/master

Then you clean up the merge conflicts and commit the merge.

The way I handle it, though, is with a separate branch, because it seems cleaner. My master branch is just a vanilla copy of the Symphony repo. First thing I do is create a second branch. You can call it ‘build’ or ‘production’ or something:

git branch build
git checkout build

Now you do all your work in this branch. You can add your workspace files if appropriate, add submodules, update extensions, and so on.

When you need to update, you update the master branch first and then merge those changes into your ‘build’ branch:

git checkout master
git pull origin master
git checkout production
git merge master

Same deal as above. Resolve any merge conflicts and commit the changes.

I hope that’s helpful. It’s worked fairly well for me. Of course, someone might have a more elegant solution. Like you guys, I’m still pretty much a Git newbie.

Craig, that’s great, I especially like the second solution. I will roll this into the Git doc I just posted.