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.
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.
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.
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!
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).
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.
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.
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.
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.
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.
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.
I much prefer it for the following reasons:
1. Branching and merging is so much easier.
2. No .svn folders littering the project. Git keeps everything in one folder, in the root of the project.
3. Git has become something approaching a de-facto standard for managing EE addons.
4. For reasons I can’t explain, I just find git nicer to work with, even though I had a nice GUI client for SVN, and do all the git stuff via the Terminal.
@Richard: 9 times out of 10 I’m just working on the files locally, but still tied to the remote “live” DB, so there is no database duplication at all. You can certainly dupe the DB and work locally, and Capistrano can help with automating that whole process. But most of the time I’m working on the template files locally, but getting the data from the “real” DB.
Do you not have latency issues when dealing with a remote server. My server is between 20ms and 50ms away from me, depending on how the internet is feeling (in South Africa, our internet is a bit patchy).
Haven’t tried it, but I assume on a page with many queries, this could be a problem. Otherwise, I think you’ve touched on a very good solution.
@Richard: There can be some latency, but it’s usually not too bad. If I know I’m only going to be working on template changes, I may make the effort to do a SQL dump and alter my config.php file to work locally, but I’ve found that most of the time, I can just point to the main DB, usually via IP address. The issue there is: your host better allow remote mySQL connections for that to work, and if they don’t, then you’re going to have to dupe the DB all the time.
