I will be presenting "Beginning Git" at 10:30am on this Saturday, 10/22 at the Bay Area Drupal Camp. Ever since I caught wind that Drupal was (finally!) moving off of the archaic CVS version control system, and started planning the Great Git Migration, I took it upon myself to be sure that I learn everything I could about Git.
The time was definitely right for me, in my walk of programming, to start using a version control system. I was writing more and more complex stuff, and I would often start off on a tangent working towards a Really Great Idea, only to determine that it was unfeasible... now what? My file system was rife with files of such creative names as "my_project.backup2.final.final.zip" and other much more useless nomenclature. True, most of my work was done alone, but it would be ridiculous to assume that nobody would ever want to collaborate or even just look at my projects.
Sound familiar?
Well, until recently, the Drupal project was on the CVS version control system. For its time, it was a tremendous program for programmers to collaborate. I'm not really knocking it (much) by saying this, but I know for a fact that I wasn't alone in that it was rather cumbersome to use. And it wasn't much fun to work on one's own computer. You really needed a server to use CVS (since it's a centralized system). Needless to say, it wasn't exactly feasible for my day-to-day workflow.
Enter Git.
Git was like a breath of fresh air. A simple installer on my Mac, and I was Up and Running. I can work on it on my own, I can bring in one or two other collaborators, and I can work together with thousands of Drupal community members. The commands are intuitive, and you can use as few as you can remember, or as many as you need to organize your project.
So, now I want to share the knowledge. I've presented this at Drupal Camp Sacramento Area in May, and I'm looking forward to this encore performance at the largest Drupal Camp ever (so far). If you want to follow along, attached is a pdf of my presentation. I'll link to the video once it gets posted.
Comments
I had the privilege of
I had the privilege of attending your "Beginning to Git It" talk twice, once at the Sacramento Drupal Camp, and again at BadCamp. I'm now starting to set up my own Git archives, and I've a couple of questions you might be able to answer for me without much effort (if it would be an effort, just point me in the right direction, and I'll chase the answers myself).
1. You demonstrated, and referenced, a Bash configuration that managed to display the current branch label as part of the Bash prompt. I thought I had copied down the reference, but can't find it in my notes. Do you have it handy to resend?
2. I find myself puzzling over the proper granularity for Git archives. On the one hand, putting my whole Drupal installation into a Git archive allows me to maintain it as a total installation, but I also note that parts of it are modules and projects that more or less stand on their own, as far as sharing with others is concerned. Is there a consensus out there about the proper granularity for Git archives? And what happens if you nest one archive inside another?
Some sort of answers
1. Here's the Lullabot article I mentioned: http://t.co/84ytC1UX
2. This is not an easy thing because there are many ways to do it and many schools of thought on the matter. Unfortunately, there is no "best practice" in the Drupal world for doing so. I'll try to describe some possible solutions for you.
First, Git isn't necessarily, on its own, the best deployment solution. If you're trying to do a full-on dev->test->prod automated code deployment system, Git may play an important role, but it's not going to be the be-all end-all. You'll likely end up using something like Jenkins for the automation. On the other hand, unless you're building a mission-critical web site along with several other developers, all working collaboratively, setting up all this stuff may be more trouble than it's worth.
Personally, unless I'm actually working on some core development, patch testing, etc., I normally don't put the whole Drupal core into Git. I'm happy enough just downloading core using Drush, or just the tarball package download. Then, I have some of the contrib modules as separate Git repositories. That way, I can patch them and stay on the bleeding "dev" edge of these modules. Some modules, if I'm not interested in working with the "dev" version, I'll just use Drush to download the recent release.
This isn't necessarily the "best" way to do it, but, as I mentioned, there really hasn't been a "best" way fully hashed out yet. Drupal has only been using Git since, what, March? And "best" for a one-man shop working on a side project is likely to be somewhat different thing than "best" for Lullabot working on a high-profile, high-performance web site, for example.
You ask about nesting one repository inside another. There's something in Git called "submodules". You can look into that, but I've heard that they're pretty complex and not necessarily ideal for this situation either.
The most promising direction I've seen is the DOG project (Drupal On Git) which is trying to solve this exact problem and find out the "best" way to do it. It's still in the very early planning stages, but you might get some ideas in their discussion. You can find more info here:
http://drupal.org/project/dog
I hope this was helpful. Sorry there's no silver bullet here... yet.