2013-10-29

Git-er dunn

So I'm a late-comer to this version control phenom called Git.  Up until basically a couple weeks ago I'd been mostly tied to Perforce for work and for my own private or local small things I'd maintain my own SVN server repo and for single one-offs even used RCS simply because it was quick and dirty and there were emacs came with bindings by default.

Oh, I was aware of Git and did some reading on it over the years and had the interest, just never had a need until recently.  I basically created the need and have been playing with it for a couple weeks now.  The need came about because Perforce licenses cost money and at work if you aren't doing development on something in Perforce for a sufficient amount of time, they "threaten" to pull your license.  Actually it's not a big deal because I can always just get a new one.  Still, I didn't like getting the notification.  More than that though, was this company-wide push to migrate towards Git from Perforce, SVN and the others.  Now that I've been using it, and given what I've read about it, not only do I understand the move but I wholly endorse it and wish I had used it before and pushed for it at my previous job. It might be the novelty and "shiny new toy" effect but I think it's pretty slick, albeit slightly obtuse in learning since it has some significant points of deviation from what I've used before and requires some re-thinking.

Initial highlights for me are:
  1. Split location development
  2. Promiscuous committing and branching
  3. Speed and Offline work

Split location development

The primary "oh, this is actually cool" feeling came when I realized that it may solve my split development-environment problem (at least the mechanical part).  What I mean is, I do/did development on different machines such as laptop and desktop and other remote machine.  I'd usually had some helper scripts and such to rsync things back and forth and keep track of what files I changed in each, always at risk of clobbering some work I had done.  It was really kludgy but necessary.  It was just easier and more convenient to develop on my laptop but I was limited because the gobs of data I needed to run on or the other needed tools/services/libraries were on the servers which my desktop could have access to but that I couldn't bring locally to my laptop.  Currently, I'm experimenting with a Git setup where my desktop pulls and pushes from the main repos on the servers, and my laptop pulls and pushes to my desktop.  So far it seems like a great way to keep things aligned and with commit changes and history preserved, made possible by branching and merges being first class features of the system.

Promiscuous committing and branching

This was new to me in terms of typical work flow.  Since branches and merges were kind of painful in the other version control systems, and because even checking work back in to a central repository with others was a time-consuming process (with regression tests, locking, merging, code-reviews, etc),  I'd basically work on many multiple things in the same checkout and check them in en masse with a single description just so I didn't have to do it as often.  Now I see I can do many local and -- more importantly-- annotated commits which is nice for collecting clusters of work related to the same goal and keeping track of change history.  And as well, I find myself now separating different work goals into different branches, even disposable ones, knowing it is still organized and relatively quick and painless to re-merge especially since it will be with myself only. In effect (if not in actuality) I get to be the repo owner and all of the benefits that entails.

Speed and offline work

I really like that I truly get to work locally.  No waiting on a central repo.  I hate when people spout nonsense that free wifi is everywhere and we're never without a connection.  Even with your own mobile wifi hotspot you don't always have a connection.  Just ride the BART for an hour like I do and see what percentage of that time you have an uninterrupted signal.  It's not that I don't wish I had uninterrupted wifi all the time, but I don't want the lack of it to gate me from being able to be productive when I'm a poor offline user.  Just as important, I really don't always want to be VPN'd into work either, which is extra annoying because I have to dig out and use a password-generating dongle to VPN in.  This is especially frustrating on e.g. BART where interrupted signal can kick me off of VPN every few minutes in some areas. Poo.  The side benefit is that since the whole repo is local and I don't need to consult with the central repo for every little thing, it's really fast.

All of this is well-known to Git users.  There are other bigger philosophical and paradigm shifting things connected to it as well.  But this is what effects me.  I hear that it was a bit more painful and/or confusing to use in the early days so it's probably just as well that I only pick this up now that it has passed the mass adoption phase.  To many I'm sure it's just another version control system, so what, we work fine with the old method, it suits us better, less to learn, the are workarounds to ease the pain points with the old system, it's still improving, etc. etc.  For me, little things like this that sort of optimize some annoyance out of existence or greatly reduce it still excite me.

No comments: