Git is a complicated beast. The Git index, if you’re coming from other VCS’s, is a new concept. Yesterday I described how I use the Git index in my workflow:
These pictures illustrate the multiple locations, or “data stores”, that host a copy of the source tree. These stores are: the working directory, local and remote repositories, and the index. In order to show more of the whole development process, the second picture also includes a “distribution directory”, for code that is being distributed outside of Git. (The distribution directory could be the deployment directory of a web site, or a compiled artifact, such as a binary, that is placed in firmware or on a DVD.)
Git‘s great! But it’s difficult to learn (it was for me, anyway) — especially the index, which unlike the power-user features, comes up in day-to-day operation.
Here’s my path to enlightment, and how I ended up using the index in my particular workflow. There are other workflows, but this one is mine.
What this isn’t: a Git tutorial. It doesn’t tell you how to set up git, or use it. I don’t cover branches, or merging, or tags, or blobs. There are dozens of really great articles about Git on the web; here are some. What’s here are just some pictures that aren’t about branches or blobs, that I wished I’d been able to look at six months ago when I was trying to figure this stuff out; I still haven’t seen them elsewhere, so here they are now.
We have a No TV in our living room.
Sometimes I think it’s our most valuable possession.
Our No TV gives the whole family somewhere between one and six extra hours every day. It’s hard to add hours to a day, but the No TV does it.
Miles uses the time for making stop-motion movies and Flash animations. Charlotte uses it to read, and write, and compose pieces on the piano. I use it for writing (code), and writing (English), and to teach myself algebra and geometry and management theory and finance. Margaret uses it for her many projects too. We wouldn’t have time for any of this, if it weren’t for our No TV.
This is an ambigram by Scott Kim, vectorized by Miles Steele, cleaned up by Dan Lewis, and put inside an OpenLaszlo application. (If you don’t see it, click here.)
Yesterday I was profiling a page that used jQuery. The page took a long time to initialize. Firebug Profile (a great tool) told me that the time was in jQuery, but that wasn’t much help — the page initialization code had a lot of calls to jQuery, to bind functions to various page elements, and most of them were harmless.
Hence, jQuery.profile. Stick this in your page, call $.profile.start() to start profiling calls to $(selector), and then $.profile.done() to stop profiling and print out something like this:
