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 first repository.
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 ingrained.