Agile Zone is brought to you in partnership with:

I'm a software architect with Lockheed Martin Mission Systems and Training. Most of my recent work has been with Java, especially Java EE (JBoss) and OSGi (Karaf), but I've worked with C, C++, C#, Ada, Python, MATLAB, and a few other things over time. Alan is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Conversational Git: The Friendly Introduction to Git

  • submit to reddit

This post is an excerpt from my new book, Conversational Git. The entire book is available online and its source is on GitHub. It’s designed to be a quick, accessible introduction for experienced developers. I’d be delighted to hear what others think.

I recently had some close friends talk about their hesitation in adopting Git as opposed to continuing to work with Subversion. I’ve used Subversion for many years, and advocated for its use. I have since jumped wholeheartedly on the Git bandwagon, so I wanted to find a way to tell the story of why I made the switch and why I think so much of the open source community is now based around Git and Git-friendly sites like GitHub.

These friends are smart people, and if they’re not convinced about Git, the problem is not them; it’s that they haven’t seen the right argument yet. There’s so much content out there about Git, and much of it is written at a level that’s way higher than my expertise. But in a way, that’s an issue. When you’re first starting out learning something, the questions that you have are way different from the questions an experienced person has. Once you’ve won that knowledge, it’s almost impossible to go back and think about what it was like when you were first learning. That puts you in a bad position to explain to someone else who’s brand new.

Git seems particularly prone to this because it’s based on some pretty complex notions of how to think about version control. In particular, once you internalize the concept of the Directed Acyclic Graph (DAG) that underlies basically everything in Git, you tend to want to explain that to new people because (a) it can help you think about how Git works; and (b) it’s cool. Unfortunately, teaching Git from a DAG perspective is IMHO the worst way to teach it to new users because it suggests to them that they have to thoroughly understand complex concepts from graph theory to use Git effectively. There’s also no question that the Git help pages use Git-specific jargon, which really interferes with non-experts understanding what a command does.

The book adopts a style that should be accessible to new users. It’s informal , with plenty of first- and second-person references. This is not a “dummies” book; I’m not going to talk down to you, and I’m not going to suggest that you shouldn’t learn complex concepts about Git. But I’m going to try to talk about how I use Git and how I see it being used effectively.

I hope the book is interesting and useful and I look forward to feedback.

Published at DZone with permission of Alan Hohn, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mihai Dinca - P... replied on Wed, 2013/10/23 - 6:09am

I looked over the book and it is indeed a good one. I mostly like chapters 8, 9 and 10. There are a lot of books about git. Some too light, some too hard to follow. And from everyone I read, I found new things. That really shows Git complexity. And it is an art to clearly explain to others. For example I found that most comprehensible basic information about merging to be here as related to any book I read.

I guess chapter 10 can be extended to an entire book. It is very important (even if users don't know) to have confidence that there is a solution if something went wrong. Lack of confidence is the root of hesitation. If a book can answer questions like: "I did A and B. But I want to go back. What to do?", then it really has a daily purpose.

I would really like to hear from people that use Git in big projects with many developers. How do you solve merging conflicts on big scale. If I have only some files with conflicts is one thing, but if I have twenty or thirty I think it becomes difficult to follow.

Alan Hohn replied on Wed, 2013/10/23 - 10:31am in response to: Mihai Dinca - Panaitescu

Thanks, nice to hear. I may add a couple chapters related to how to undo things; like you say there are a huge number of possible scenarios.

If I could find a simple way to explain how to find detached commits, I'd definitely write that up. The times I've really messed myself up with Git and had to resort to extraordinary measures to get things back have all been related to detached commits or a detached HEAD.

Motaz Mohamed replied on Wed, 2013/10/23 - 10:41am

Thanks , really great work . 

Jim Bullock replied on Wed, 2013/11/06 - 4:21pm

Hi Alan,

I think your hook is to address "What problem are we really trying to solve, here?"

Torvolds is explicit about this in his Google talk delivered shortly after GIT got some traction. If you can get past the Linus-ness, he's talking about several particular workflows / use cases / user stories, and critical features you need to do them successfully. GIT (and Mercurial) support those things better, augmenting the humans in the process vs. making things worse. There was a related talk - may still be out there - by the then-CTO for Cheezeburger Networks that reads the same. Moving to Mercurial made some parts of their development workflow easier, and other things possible.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.