Thread

Hello all,

I’ve started a new series of posts over at my site discussing how I use git to manage ExpressionEngine websites.

The primary reason for writing the posts is to start a conversation from which we can all benefit—myself included—in the hope of establishing some “best practises” for managing EE sites with git.

Rather than opening up comments on my site, I’ve decided to host the conversation here, in the hope that more people will pitch in, and more EE developers will benefit from the discussion.

So, by way of a conversation starter, perhaps some of you experienced git / EE users could offer some insight into your workflow. And the novices might want to pitch in with suggestions on what I should cover in subsequent blog posts.

Cheers,
Stephen

P.S. Almost immediately after publishing my first blog post on this subject, I came across this very in-depth article by the ever-informative Dan Benjamin.

Whether this renders my own series of posts irrelevant remains to be seen, but either way I still think this forum conversation is worth having…

I have extensive notes myself from putting devot:ee on Git (although I am not using Capistrano for deployment at this point) that I plan to publish as well. I don’t think anyone’s articles will make anyone else’s articles irrelevant - I think they’ll ultimately complement each other. For example, I don’t see anything in Dan B’s article about setting up the config.php file (I have some nice tricks in there), and I have a completely different .gitignore file than his - both things that I’ll touch on, and you might as well.

There are also things like the tweak/hack you must do to FieldFrame to make it work across servers easier, as well as ideas about relative paths in the Control Panel.

May all of this be so, so so much easier in EE 2.0.

(Wow, this was my 2000th post here)

Hi Stephen,
Not an expert in svn but should not EE template version be enough?
Unless, that is, you have a multiple developers working on the same project.
Curious what other people have to say…running WAMP and having local copies is usually enough for me.
All ears here. 😊

@Ryan

Congratulations on hitting the 2k.

For example, I don’t see anything in Dan B’s article about setting up the config.php file (I have some nice tricks in there), and I have a completely different .gitignore file than his - both things that I’ll touch on, and you might as well.

Now see that’s the sort of thing that I’m interested in hearing about. I understand that you’ll probably want to save the good stuff for your devot:ee article(s), but it would be great if you’d share a bit more about that here, on the forums.

@lebisol

Not an expert in svn but should not EE template version be enough?

I don’t know about you, but I’ve got a lot of files—images, CSS, JavaScript etc.—that live outside of the EE templates. Not to mention custom add-ons I might create for a specific site. Git takes care of all of that.

It also makes it easy to branch projects so (for example) you can have a master branch relating to the site in its current “live” state, and other branches for development of major new functionality. That’s really useful for when you want to work on a new section or feature, but still need to perform ongoing maintenance updates.

If you’re looking for a more general introduction to things git, I found the PeepCode screencast very useful when I first started learning it.

Cheers,
Stephen

Thank you Stephen and I see your point. Organizing it all with system folders gets easily buried or organizational logic gets lost after a while.

Thanks for the links!

edit: After some digging I found this for us windows users.

After some digging around it seems that git is mainly available for dedicated servers, or at least that seems to be trend with hosts.

I am curious how do you handle binary files?
From what I see git vs. svn not much difference in EE world. The only place I see that EE users can benefit is for Templates (have to be run as files). Assets and db still have to be handled separately…seems like a lot of effort for something that can be easily done with ‘save-as’ and comments in files….
Am I missing something?
Thank you for sharing!

Hi lebisol,

I am curious how do you handle binary files?

There’s nothing to stop you including binary files in a git repo (or Subversion, for that matter). Database stuff is a separate matter, and can be a bit of a pain, it’s true; you could probably schedule backups to a version controlled SQL file, but I’ve never gone down that route.

Assets and db still have to be handled separately…seems like a lot of effort for something that can be easily done with ‘save-as’ and comments in files….

Actually, once you’ve got it set up, it’s not much effort at all, and is a lot more robust than simply adding comments to files (or duplicating and “version-file-naming” them).

As I mentioned above, branching is also a big win, and is very easy in git. You can switch between an “in-development” branch, and a “master” branch with a single git command, which is incredibly useful for local development (or even client preview sites).

Imagine a client wanted you to revamp the “products” section of his site — change the layout, add new functionality, the works. It’s going to take a few weeks to implement all the changes, but during that time the client is still pestering you for minor tweaks and amendments to all areas of the site, including the existing products section.

Without version control (and even with SVN), this can be a real pain. You either have to put the client off until the new products section has been completed, and then do all the other amendments, or maintain two totally separate versions of the site, and hope you don’t forget to copy your minor “live” site tweaks over to the “new product section” site.

With git, you can create a new “products” branch, and flip between the two with a single command (assuming you haven’t made a bunch of database changes too… that’s when things get tricky).

If you make some changes to the “master” branch, you can quickly roll those into the “products” branch, again with a single command. Finally, once the new products section is done, you can merge it back into the “master” branch, and deploy it to the live server.

It’s also possible to manage addons as git submodules, so you can pull the latest versions from a public git repo (like GitHub), but it’s probably best to save that for another day (and blog post).

Hope that gives you some food for thought.

Cheers,
Stephen

Thanks Stephen very much for the follow up.
It does open a few possibilities even if it is a partial usage for someone like me. It might require some adjustments in a work flow but worth it in a long run.

If either you or Ryan publish an article please post/link back I would love to learn few more tricks.
Thanks again!

If either you or Ryan publish an article please post/link back I would love to learn few more tricks.

I’m planning on publishing a short series of posts documenting my workflow, with this thread playing host to any ensuing discussions. I’ll be sure to let you know when the next installment is published.

Cheers,
Stephen

Just a quick note to let any passers-by know that part two is ready for your reading pleasure.

Whilst the first installment in this series was little more than an introduction, this one walks through the process of setting up git, and lays the groundwork for your day-to-day development tasks.

As ever, comments, questions, and suggestions are welcomed.

Stephen

This is great - now I don’t have to write anything 😊

How do you find the time? Don’t you have client work? Sheesh!

Actually, everyone might learn something from everyone else if all these Git articles start coming out. I did not know about those SSH aliases. Thanks for that tip. Uh, and just to be sure…this .ssh config is local? I always get confused about whether instructions are referring to local or remote when I’m supposed to type something in.

How do you find the time? Don’t you have client work? Sheesh!

Shh, don’t tell the clients I’m doing this.

Actually, everyone might learn something from everyone else if all these Git articles start coming out.

That’s what I’m hoping :D

I did not know about those SSH aliases. Thanks for that tip. Uh, and just to be sure…this .ssh config is local?

That’s correct. Should be in your user directory, so ~/.ssh/config

Cheers,
Stephen

Hi Stephen

Watching with interest and waiting for the series to be complete before giving this a bash.

The bottom line for me is that ExpressionEngine is so tightly interwoven with the DB, that any meaningful development would require changes to the database (adding a custom field; creating a new template), which would mean creating an SQL patch file for your specific branch of development.

I don’t know much about databases, but my worry is that, for instance, in developing some functionality I would create a couple of new entries in the weblog table. Each is given a specific entry_id, as we know. Then I would be continuing with the live production site, which would also get weblog entries with the same entry_ids. There is a conflict right there. So I would have to be very careful when migrating the branch back to the production site. There are probably more complicated examples, for instance creating a new template.

How do you answer this problem?

Thanks,
Richard

Hi Richard,

Thanks for pitching in, I’m glad you’re find the posts interesting.

Regarding the tight integration of EE with the database, and how I address these problems, the answer is I don’t. Hardly the response you were looking for I’m sure.

If somebody has a solution to this problem, I’d love to hear it, because I’ve never managed to find one I’m happy with. Whenever branched code (in particular) requires database changes, it’s rarely anything other than a pain.

So why even bother with git?

Simple; it’s a lot better than not bothering with it. It may not be a 100% perfect solution, but it’s saved my bacon on more than one occasion already (and SVN did the same before that), so—for me at least—it’s worth the very minor setup cost for each project.

Cheers,
Stephen

Hi Stephen

Thanks. Even if database changes have to be done manually, I’d love to hear what processes people follow… I understand there’s no easy solution, but there must be some workaround, even if it means dumping SQL, diff-ing the changes and then assessing one by one what to do. lol. that could be fun.

Another question. Why git instead of SVN?

Thanks,
Richard