Welcome to the first part of the book project series. Without further ado, let’s get started from discovering how to git gud in Git.

Undoubtedly, there are many books about git, however, the Pro Git by Chacon seem to be one of the most recommended positions and it’s for a reason.

I picked it a few weeks before the company I work at decided to move from the SVN to GIT, making what’s supposed to be a huge step forward. It turned out it really was.

Through the first 100 pages, Ben explains the concept of git, which is a decentralized versioning system and underlines what distinguishes it from other versions systems i.e. SVN, CVS, and Mercurial. Additionally, the author covers a number of topics: git customization, setting up a git server, or repository migration, which may help you during git initial setup. Chapters are well structured, precise and thrift. Concepts are explained in a clear manner and easy to understand. The book helps newcomers with getting to grips with the concept of distributed work using branches and provides several user stories, which cover most of the daily usages of the versioning system.

It’s a great chunk to start with in order to build a solid base of knowledge. Even readers who are already familiar with the git mechanics may find something interesting and non-trivial like chapters covering the git internals. After reading Pro Git I felt comfortable enough to navigate toward the git official documentation with a lot more courage.

Personally, the most important takeaway was the function called bisect, which I didn’t know existed before reading this book. It got into my mind so deep I decided to immediately put it into action. In case you are not familiar with it, here’s a short explanation from the official documentation:

This command uses a binary search algorithm to find which commit in your project’s history introduced a bug. You use it by first telling it a “bad” commit that is known to contain the bug, and a “good” commit that is known to be before the bug was introduced. Then git bisect picks a commit between those two endpoints and asks you whether the selected commit is “good” or “bad”. It continues narrowing down the range until it finds the exact commit that introduced the change.

https://git-scm.com/docs/git-bisect

Using it along automated tests allows to quickly locate the commit that broke it, which may really speed up your work.

Would I recommend the book? Definitely, just bear in mind you can really skip half of it, if you are not interested in the migration, server picking, choosing a communication protocol, or the git internals. Otherwise it’s well worth your time.