Yeah, okay -- I am now totally sold on git

[jducoeur]

[For programmers only. A bit late to the party here, but still worth a burble.]

Querki's been built on git from the start, so I've been using it for a solid two years. But I confess, that decision wasn't made out of any deep analysis -- I had simply decided early on that Querki was going to be mostly open-source, and all open-source projects these days are on GitHub, so I went with the flow. I'm starting to realize now that I never truly *understood* git until recently, though.

The thing is, when you have decades of experience with Source Code Management tools (and I've been using them longer than most -- I started out using Intermetrics' homebrew derivative of RCS back in 1987, and built a pretty state-of-the-art GUI-based framework system for GM in the early 90s), you get certain assumptions very ground into your brain. The notion that there is a "master" server somewhere is very deep-rooted. Moreover, the notion that branching and merging is a Horrible, Painful, Agonizing, Fraught Process becomes -- well, basically it becomes a reflexive twitch. When you've received enough electric shocks, you learn not to reach for the cheese behind that door.

(Granted, some SCM systems have always been better than others. But none have been great, and spending a couple of years working with SourceSafe taught me to *deeply* distrust trying to do anything "fancy" in these systems. Actually, working with SourceSafe mostly taught me not to trust SourceSafe for *anything*, but that's another story.)

Somewhere in the past few months, though, I've finally started to *get* git, and the benefits of always working in branches. Take today for example. I started out spending an hour trying to make an enhancement (progress towards the concept of "Choices"), only to discover that it was going to be harder than I expected. Humph -- don't have time to deal with this before Pennsic. What do I do with this code? Well, there is this "stash" concept, to just stuff the code away for now -- that works. Wait, that's going to be a pain if it takes a month or two before I return to it. Try an experiment: create a new branch for this project, and unstash into there. *poof* -- I now have a branch to hold this work, to get back to when I want it.

Engineers who are used to more-traditional SCM systems (which is most folks in the corporate world), I'd encourage you to play around with git, and get a sense of it. It's radically different from traditional models, and I believe there are some things it's not ideal for. (Eg, versioning of large binary blobs.) But for code-management it's a hoot: when checkins are local and instantaneous you checkin more frequently, and the branch-early-and-often mentality really changes the way you work, by making it easier to keep projects going in parallel. It's optimized for distributed open-source projects, but even for a one-man show like mine, it turns out to work awfully well...

Comments

[goldsquare.livejournal.com]

You are a multiple-person project.

There's the man you are, the man you were, and the man you will be in a month.

Documentation and proper code management are all part of how the man-you-were communicates to the man-you-will be, and keeps you from having to remember all things, all the time.

See, I forgot that there were SCMs where branches weren't cheap

[marphod.livejournal.com]

My second professional job used an at-the-time cutting edge SCM; while there was still a central server and a 'main' branch, every workspace was a virtual private branch. Checkins to the private branch were cheap and could be done without connecting to the main server. Re-basing was simply drag the workspace to the new parent. The default was to throw out intermediate, local checkins (and merge the local comments) when pushing the changes back to the base, they could be saved, as well. (there were issues; making new branches was cheap, but workspaces weren't. Nothing like clearcase's wink-in on build -- that is, stashing binary targets on the server, comparing a hash of the build environment, and just grabbing a binary if the environments match -- but it was so much better than anything else I had used)

As my prior experience were mainly with RCS and ClearCase, I figured all modern SCM did that. I've been shocked using Sourcesafe, perforce, and other SCMs since then. Those seemed like such a basic idea, and yet.

[metahacker.livejournal.com]

I agree on all fronts, especially the electric shock part...

Merging is also a lot more sensible than I'm used to, and hunk-by-hunk committing is very nice when you need it. Oh, and git commit --amend, because I always forget _something_.

But most useful is the n-way coordination with self. Got three versions in four different places? No worries...it'll all merge in the end. Just push and pull until you figure it out.

Oh, and the "git on a stick" thing. (Cause everything's better on a stick!) I keep a repo on my thumb drive, and have confidence I can make changes...wherever...even without network connectivity...and later merge them in. So nifty.

[jducoeur]

Haven't gotten around to trying git on a stick yet -- by the nature of Querki, working on it without network connectivity is problematic. But I can see that that might be a lot more useful if I was doing anything serious away from my desktop machine...