I’m a git user, but not a heavy one. I’ve cloned repositories from github, and even submitted a couple of pull requests. Most of the work I do, however, is as a solo developer. For that reason, I feel like the superstructure of git is not completely ingrained into my workflow. I think I was hoping to find in this book a catalog of best practices and some example workflows so that I could examine my one git usage patterns, and adapt them to be more effective. What I found was somewhat different.
This book is not (just) a user’s manual. It approaches the topic of version control not in the abstract, but through the lens of the way git does things. This makes for kind of an odd reading experience. It’s clear that some of git’s features are designed specifically to alleviate headaches common in large projects, but it’s hard to come up with cases that illustrate those needs without being overly complicated or completely contrived.
One specific example that comes to mind is the difference between merging and rebasing. The difference seems subtle, and I’m pretty sure that even after reading the relevant sections of the book, I’m not completely clear on why or when one would choose one over the other. The main impression I got was that it is at least partly a matter of personal preference, but I don’t feel like I have enough context to understand what would lead to one preference or the other.
The book feels like a pretty complete reference, though as a non-expert, I’m not really equipped to say how much of the outer edges of git-dom are covered. Certainly the discussion of git internals seemed strong, and the figures helped a lot in elucidating the text. Ultimately, though, I personally want to use my version control system without thinking too much about what it is doing or how it is organized. This book contained enough detail to illustrate that the minds behind git put a significant amount of thought into solving some difficult problems (the way they use hashing to save space seems pretty clever to me), but they’re not problems that I personally find all that interesting.
To summarize: I’m glad to have this book on my (virtual) shelf, and I learned some things from reading it. I’m sure I’ll go back to it as a reference, but for the most part, my needs are simple enough that it was overkill. For people who are diving in to a large scale project, or want to get a handle on git’s internals, I think it could be very useful.