We are considering moving off of Subversion for version control and
so I have been investigating more modern DVCS tools such as
Mercurial and git. I use Mercurial for all of my personal
projects, and feel fairly comfortable with its basic work-flow. I
wanted to pick up a book on git, and the number one recommendation
when I asked on Twitter was Pro Git by Scott Chacon.
Inspired by Gene Ambaum and Bill Barnes’ review short-cuts, here’s my
review for the impatient reader:
Why I picked it up: I needed to learn more about git to decide if
it was the right tool for us and how it would fit into our work-flow.
Why I finished it: Chacon’s writing is clear and engaging. He
covered all of the tips for using git that I wanted and then included
some implementation details that are useful for understanding DVCS
theory, but not absolutely necessary for using git.
I’d give it to: A developer learning or evaluating git, or
researching DVCS tools in general.
The content of Pro Git is available for free from progit.org.
There are download links for the PDF, Mobi, and epub editions, or you
can browse the HTML version on-line. I purchased the paper edition,
published by Apress. It isn’t entirely clear which version is more
up to date, though, since the PDF I downloaded only contained a
placeholder for chapter 1 (“Introduction”).
Contents of the Book
Chapter 2 gives an overview of version control system types to explain
where git fits in. It also covers the features of git that make it
different from centralized tools, and explains why the data model used
by git ensures the authenticity of a repository’s contents. It
concludes with instructions for installing git and setting up your
Chapter 3 explains how to use the basic features of git for adding
files to a repository, modifying them, tracking those changes, and
distributing the changes to other repositories. Branching, a
fundamental concept in git, is covered in chapter 4. The book covers
the basic mechanics of creating and working with branches, as well as
suggested work-flows for using them effectively.
Chapters 5 and 6 talk about collaborating with git. Chapter 5 shows
how to set up a central git server. Three options are discussed, ssh,
HTTP, and git’s own protocol. I only skimmed this material because it
was not relevant for my evaluation. Many other readers working on open
source projects will probably be able to skip it, too, since it is
easy to set up public repositories on hosting sites such as Github.
Chapter 6 covers distributed work-flows for sharing code with other
developers. It includes several common scenarios such as maintaining a
central source, using lieutenants to screen changes before they go
into trunk, etc. This information was very useful for my evaluation
because I was able to see immediately how my company’s work-flow would
map to git’s feature set.
Chapter 7 goes into detail about some advanced usage features. I
expect this information to be more useful after we have been using git
for a little while. Chapter 8 is about options for customizing git,
from basic settings like your identity, to server-side hooks for
automating changes on deploy. Chapter 9 talks about how to use git
with other version control tools, either as a way to import data into
git or by using git as a front end for systems such as subversion.
Chapter 10 covers internal implementation details of git. I found this
information interesting, but it probably isn’t that relevant for
someone who just wants to use the tool.
Pro Git is an excellent book. It is clearly written, covers all of
the information you need without introducing any unnecessary
complications. When I looked at git several years ago the information
I found on-line was confusing and turned me off. After reading through
Pro Git and experimenting with some of the examples I felt ready to
move all of my source code into git for safe-keeping. I don’t
anticipate needing another book to explain any more details about
using git as a version control system.
I expect to keep Pro Git handy as a reference as we plan the
migration of our source code repository from subversion to git, and
for a while afterward, until the commands I need to use become