Clone ... What could possibly go wrong?
If you're a coder, you've already heard about distributed version
control systems (DVCS) and git in particular. I
was content, almost complacent, in my usage of subversion to manage my
source code, both for personal projects and at work. Subversion was
intended as a "compelling" upgrade for CVS, and the next version
control system (VCS) I used had to be equally as compelling. I think git
has cemented itself as the preferred DVCS within the Open Source
community. No doubt services like github have
helped popularize it over bzr and mercurial. I've switched over to git
over the course of the last month, these are some of my motivations and
a record of what I learned along the way.
Why not stick with Subversion?
Subversion, since it has been around longer, enjoys better support in
text editors, IDEs, and GUI front ends . It's easy to setup a
repository that you can share with a collaborator, or sign up for a
hosted repository. It's killer feature is the ability to fetch parts of
a remote repository via the svn:externals feature. I'd used that
extensively to organize projects and track 3rd party software such as
Pressflow or Zend Framework. Git does not have an alternative as
straightforward as svn:externals.
Over the last year I noticed that I wasn't committing code as often as
I should be, resulting in a lot of conflicts when I did try to do an
inevitably large commit. Ideally, I would want to have a lot of frequent
and small commits. When I tried to use branching and merging in
Subversion, it was tedious and felt that one misstep would result in
lost work or a bad merge. Even though merge
tracking was added to
subversion in version 1.5, my early exposure to it has caused me to
avoid it like the plague. That's a shame, because branching and merging
is very useful for keeping new features from mixing in with mainline
development until it is ready. Finally, at work we'd moved to a repo
hosted on assembla.com and lost some useful pre-commit hooks for keeping
PHP syntax errors and debugging code from being committed. A year later,
it seems our group is the only ones still using this repo so I've been
contemplating moving back to one under our control.
I know one option would be to use git-svn to use git locally and somehow
push changes to the subversion repo, but I preferred to ditch the latter
wholesale and not worry about having two systems in place. There's
enough to keep track of as it is and version control should simplify
things, not complicate it.
Git has quite a learning curve
Understanding the terminology of git is confusing, particularly if
you're used to working with subversion. It's not just your working
copy and the repository anymore - now there's a stash, the index where
your commits are staged, the local repository, and the remote (or
origin) repository. A good front-end can really help, if you are on a
Mac I'd recommend using one of the active forks of
GitX.
This interactive cheat sheet also helped me to
figure out git and what some of its commands do (Hint: click on the
colored boxes). I think you'd be better off if you could somehow forget
everything you ever learned about subversion.
You're work flow has to change too, since you now have to remember to
push, that is send, your commits to a shared repository, and also fetch
and merge (or pull) the commits that your colleagues have pushed to a
shared repository. A good front-end or first-class support in your
editor/IDE of choice really helps here.
Git is useful once muscle memory kicks in
Once we initialized our repository and started committing changes, it
didn't take more than a day to get comfortable with using git. There
were a couple instances where I was jumping to my co-workers cubicle to
figure out how to send my changes to him, or to learn about the
difference between git's fetch and pull commands. Google and
StackOverflow were most helpful in finding answers to our questions and
explaining the commands we needed to invoke.
I've found myself committing again quite frequently, after finishing
small and discrete fixes and features. In the long run, having a more
fine-grained record of changes will be useful. As promised, git also
makes branching and merging extraordinarily easy. Its trivial to be
working on a new feature branch, switch to the mainline development
branch to commit a minor fix, the switch back to your branch and merge
in the fixes you just committed. It takes just a handful of commands and
you don't need to worry about version numbers or direction, it just
happens. I've found myself doing that 2 or 3 times during the day
without worrying that I was one command line switch away from total
devastation. Another cool feature we found in git, via the GitX front
end, is the ability to stage and commit just some of the changes within
a file.
If you've recently switched, or are contemplating a switch, to using
git, please share your thoughts and experiences below. In the near
future, I'll be sharing the details of the work flow we've established
and how to take advantage of git's hooks to do useful things before and
after commits.