I've been kicking around the idea of a book on Git. I think it's a great tool, but there's a lack of an accessible guide to get started with. In any book on a new technology or tool, there's the initial sales pitch. Why should you use this? How is it better than what you're already doing? Than its alternative? I'm trying to answer those questions right now for myself. It's only a few paragraphs of the entire book, but I think having the answers will help keep me on track for the rest of the book. Here's what I have right now.
Distributed
One of the main reasons for using Git over the two traditional version control systems—CVS or Subversion—is its distributed architecture. Instead of having one central repository, or one central point of failure, each developer clones the entire repository. Changes can then be pushed back to a central source, or a completely different source.
In the workplace, this allows for multiple layers of code review before the code makes it into the main repository. Each developer would push their changes back to their team's repository, with the team captain pushing changes back to the main company repository after they've been reviewed and the unit tests are verified.
In the open-source community, distributed means that no one company or person controls the repository. Any developer could easily publish their changes with the exact same history up to their change. These changes could then be incorporated by developers that are still tracking the official repository, allowing them to try them out without leaving their version control software unused.
Easy Branching and Merging
Branching within Git is easy and without much overhead. Tracking multiple branches, merging changes from many branches in to one, tracking changes across multiple merges. All of these are considered esoteric in most version control systems, only for the most advanced user. While they still take some practice in Git, doing them is straight forward.
Tags are Just Tags
If you moved from CVS to Subversion, you were probably surprised the first time you realized you could change code that you "tagged". Git enforces the "gentleman's agreement" found in Subversion by not allowing anyone to write directly to a tag, treating it as just a named snapshot.
Network Not Required
It is easy to forget in the age of always-on broadband connections, but we don't always have a network connection. Since your working copy is your repository, you don't need access to a network connection to track changes. You can safely work on your code on your next plane trip, tracking your changes the entire time, then sync with your repository after you've landed.
Can Communicate with Subversion
In the centralized world of Version Control Systems (VCS), Subversion has become the defacto standard for new servers. Having the ability to communicate with SVN means that your entire company does not have to switch to Git just to suit one team or one developer. They can maintain their copy of the repository along side the existing infrastructure and push and pull changes to Subversion seemlessly.
Anyone out there using Git have anything more to add? What's the obvious thing I'm missing?
6 comments
To be true I'd have to point out that Mercurial has also similar features as "hg rollback" and 'transplant' extension. I don't know about Bazaar, there is probably something similar.
Such making history more clear can be done sensibly _only_ if publishing step is separate from commiting, in short: only in distributed version control systems.
Another wonderfull feature is git-bisect (or Mercurial's "bisect" extension) to find which commit introduced bug in possibly nonlinear history. It speeds up finding bugs tremendously... if you create small, well contained commits: see above.
http://weblog.masukomi.org/2008/02/04/some-thoughts-about-git
and J. Bruce Fields, main contributor to "Git User's Manual" (Documentation/user-manual.txt) distributed with Git.
Comment feed for this post