Pro Git

Before I begin, an introduction is in order, to provide a little context. I'm a Windows .NET developer, and have been using Git for the past eight years or so. I use it in both my day job (the projects we work on are all source controlled in Git these days), but also in my writing business, to source control the Scrivener projects for my books. It's a fantastic tool for version controlling any kind of file you can think of.

Although I am comfortable with various graphical wrappers, I've also always prefered the Git Bash interface, perhaps because I've always liked Bash's simplicity and elegance, having played around with various flavours of Linux over the years.

With that out of the way, what did I think of this book?

I thought I was pretty knowledgable about Git before. I was wrong.

This book is a fantastic reference, and it showed me that the things I was using Git for barely constitute 10% of everything it's capable of. It's not like I've been doing this wrong necessarily; it's just that there are so many better ways to achieve many of the things I've been trying to do. For example, I knew about rebasing, but I've always been a bit afraid of it. I'm going to be using it more from now on (although as the book points out, I'm going to avoid rebasing anything I've already pushed up).

I also can't tell you how many times I've made a commit, forgot to add a file, and then had to make a second commit immediately afterwards. I'll be using git commit --amend more often now.

Finally, I can't wait for an excuse to use git bisect to find the exact commit where something stopped working!

Another thing I never really understood is why you would use fetch and not pull. Although I now understand the difference much more clearly, I'm still going to keep using pull (perhaps with --rebase, though), since I don't remember ever being in a situation where I had more than one remote for my repository.

This book is staying on my e-reader, and I'll be referring back to it constantly.

On the downside, the formatting of the Kindle Edition isn't great. I like to read white text on a black background because of my visual disability--I need the contrast--but for some reason, clickable URLs in this book (and there are many) are coloured in dark orange. Also, the code samples are a bit difficult to follow at times, because they're indented and don't flow very well on the large font size I tend to use.

Speaking of code samples, all git commands embedded in the narrative are formatted in fixed-pitch font (which is a good thing), but that formatting is inconsistent, so you sometimes see things which you think are supposed to be part of the command, but they're actually part of the narrative, or vice versa.

And the index at the end isn't linked, which makes it completely useless since there's no way to click on a term to go directly to that chapter.

Other than that, it's an entertaining and informative read. I nodded and smiled a few times, as the authors describe some pain I've already been through, but I stared at the screen and went "Wow! I never knew that." many more times that that.

A reasonably clear introduction and explanation of git. The first part does a good job at explaining things for new users, and is especially good at pointing out saner ways to do things that were added in recent versions of git. It seemed to cover most of the stuff I've learned the hard way, and I found one or two new things. The only glaring omission is it didn't seem to cover git reset at all.

The chapter on managing a project with git covered problems I'm just starting to encounter, so was appreciated. The section on subprojects showed all their many warts; candor appreciated. The coverage of subtree merging was entirely new to me and very interesting to see. The final chapter on internals does a good job of really getting down and dirty at both the git database and wire protocol levels.

The only things I didn't like were some slightly shady bits of sysadmin advice. In at least two places the user is advised to set up things in an insecure way. (I hope to get these corrected.) In other places the user is walked through cloning a project from git and manually installing it -- even though apt-get is used to install other things on sometimes the same page.