Having just gotten at least my development site up and running with Git I was looking into how to manage all the different parts of an EE project as sub projects (repositories). I was trying to avoid git submodules like the plague because of my past experience with them (Drupal). If you're new to git you're likely to mess something up there down the line. After much research and playing around I wound up using git submodules as the problem wasn't with this aspect of git itself, but with my misunderstanding of the inner workings of git.
I highly recommend first playing around a little with git to get it to help you achieve a few objectives.
Some of them might include:
- Managing EE versions.
- Managing third party add-on versions.
- Managing "forked" add-ons (e.g. on GitHub you can copy someone's git repository verbatim as if it was one of your own and modify it to your heart's content!)
- Managing assets/scripts/libraries/whatever shared between sites
- Flipping between snippet/template code for a development vs. production site.
- Making a quick fix for production site while working on major changes for development without losing anything
- Have a history of all the changes you made whether in your templates or add-ons (this is especially great when code you introduced... also introduced bugs)
Simulate an actual need in EE that isn't being fulfilled, use the resources others provided to get from A to B, try to use command line for the commands. Also have a git GUI client handy if just to see the history. (SourceTree was recently released for Windows, I've been using it on the Mac myself it's been great.)
Once you have a feel for it it will help immensely to have a better understanding of the inner workings of Git. For that I highly recommend the following:
This will help you understand the nuances of merging, rebasing, having a balanced history. Some important notes... a branch is not actually some kind of record of your project, a branch is just a 40 byte file. A commit is what actually contains metadata if you will of history. Branches and tags are references to commits, commits that are referred to along with their ancestors are the ones that are kept. You can branch away all you want, it is inexpensive. This will also help you understand fast-forward and non-fast-forward. If the commit already exists (ahead of your current work/branch) and you're merging it into your current branch or whatever, all git has to do is point your branch to that commit (fast-forward). If you want to create a new commit altogether, say, for the sake of showing linear history, you could do git merge --no-ff <commit-ish>
.
After studying those two materials (amongst others, but those provided the bulk) I was a lot more comfortable with tackling EE as a super project with EE, add-ons, sites (snippets, templates, stash templates), and assets as submodules. Once you're there, too, you may want to look into these two Q-A's to set up your .gitignore
file:
Since you're on Windows you can't use symbolic links to split your add-ons' system vs themes directories. You may want to monitor this thread and see what epocsquadron comes up with:
Personally my site's structure is something like this with heavy usage of symbolic links:
/ee2
/sites
/add-ons
/assets
Where ee2 is a repo for EE, sites has repos e.g. like default_site
which contains all aspects of EE that are site-specific such as templates
and snippets
, and assets
are other third party stuff that didn't seem to belong anywhere but warrant sharing/versioning.
(On the subject of assets
... I also modify my nginx virtual host config for the site to cascade certain urls, e.g. should /images/
belong to ExpressionEngine? A site like default_site
? What about /js/
and /css/
? For certain folders I don't see why they should have to be in one place, so I figure out which directories share them, have priority, and then use location directives, named location directives with if statements to cascade submodules.)
I haven't had time to look into deployment, continuous integration, etc. My workflow is probably going to be faster with just working in an editor (Coda 2) and uploading from it as I go along.