Hacker News Reader

Comment by globuous | Hacker News Reader

No, but there's a book called "Pro Git" by Scott Chacon and Ben Straub that popped up on HN not too long ago. It does explain git on the lower level without going into the git source code.

This book is over 500 pages, but chapters 1 to 3 will get you up and efficient within 2 hours. Especially chapter 3 (I skipped to it, I kinda knew the basic git commands from "experience"), which goes over branching and how it works. It explains how snapshots are handled and what points to what, which make working with multiple branches locally and remotely a pleasure actually.

It's honestly not to hard to get decent at git. Although I never realized how much of a tool git was until I heard about people writing 500 page long books about it.

View on HN

I never realized how much of a tool git users were before I knew there are 500 page books about it....

This whole thread is evidence of two opposing viewpoints: "git is too hard" and "git is powerful, professional tool and that requires some effort".

I believe those making the latter point misunderstand the first group (to which I belong): I'm not opposed to putting in some time to learn a tool that's central to my craft.

But git seems to often be complicated not because of the complexity of the underlying problems, but because of choices made in its implementation.

Consider: If you have a decent understand of information theory, you'll be able to use any database system within a short time, even if you never had heard of SQL before. Indeed, with a few years of SQL, you'll quickly understand NoSQL systems as well – coming from Postgres, I was productive in Redis within half an hour.

But no amount of experience with VCSs will allow you dive into git without hitting a brick wall.

Git is a powerful, professional tool that requires some effort, primarily because the UI was accumulated, not designed.

It also was designed for a use case that almost no one actually does which is distributed version control.

Most people use it like a svn with better branching and merging.

Everybody who's ever forked a project on GitHub is using it as distributed version control, and that's a lot of people, so I don't know why you say almost no one actually does distributed version control.

I'm quite certain most of these are sure they are using github and see no difference between it and Git; and "version control" term gives them headaches in same way as "currying" or "first-class function".

Reply on news.ycombinator.com