Version Control with Git, by Jon Loeliger and Matthew McCullough (O'Reilly, 2012) is just what a software developer needs to get productive with this sometimes-confusing SCM system. The first edition helped me learn the fine points of Git when I was trying to figure out how things were hooked up, and the second edition is just as helpful as the first, with some useful updates for the fast-moving Git scene.
Don't expect a pure "cookbook" introduction, though. Git lets you do some powerful stuff on your local development system, but you can't really make it work without understanding its basic data structures and some of what it does under the hood. A pure Git cookbook telling you exactly what to type and when would get you into more trouble than it would be worth. However, this excellent book combines clear explanations of Git data structures with good examples of real-world commands, along with plenty of clear diagrams that show how Git works.
Version Control with Git includes clear explanations of the data structures that power
the distributed version control system.
Last I checked, Git has 154 different commands, most of which a real developer will never use regularly. But what the authors call the "arcane" commands can help you understand what Git is doing for you when using the more common advanced commands such as "commit." A useful pattern that occurs several times in the book has you building up to a regular Git command by doing the underlying arcane commands first, and then the normal operation.
Once the basics are taken care of, the chapters on real-world SCM operations such as branching and merging turn out to be a mix of high-level problem solving with the underlying Git guts. When you're learning how to do a "git bisect" to find a bug, or abort a merge, you'll get the computer science material, not just the steps to go through. So by the time the book gets to complex subjects such as how to rescue your work using the "reflog," you'll already understand what the relevant Git objects are, and how having a reference to the right one can solve your problem.
Submodules are tricky, and the book gives you fair warning about using them. One piece of quality advice is, "Although [submodules are] a practical solution to Git's desire to have relatively small repos (1 to 4GB total) compared to several-hundred-gigabyte SVN repositories, strategic developers should consider solutions that link projects on a binary or Application Programming Interface (API) level rather than at the source level that submodules provide."
At Perforce, our Git-using developers have found that remapping Git repositories with Git Fusion is much easier than setting up submodules. With remapping, each developer can work in a custom workspace that spans all needed parts of the project. I plan to get in touch with the authors and let them know about remapping before the next edition.
If you are the "Git person" at your workplace and would like to prepare to take questions from your co-workers on how to work out complex merges and misunderstandings, this is the book for you.
Don co-founded the Linux and web consulting firm Electric Lichen, which was sold to VA Linux Systems. Don has served as president and vice president of the Silicon Valley Linux Users Group and on the program committees for Uselinux, Codecon, and LinuxWorld Conference and Expo. He was a key organizer for Windows Refund Day, Burn All GIFs Day and FreedomHEC. He has written for Linux Weekly News and Linux Journal among other publications.