The author says that the problem is: > I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can a

The author says that the problem is: > I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can add their ideas. And then we can have a merging of our ideas, and eventually test out if it works, and have it out there and ship it. Fundamentally this is the problem. If this is your use case, then git is not for you. But this is not really a use case because people have not thought through the complexity of what a "merging of ideas" means. If you want the simplest version of this, just use a google doc -- you get history, collaboration, all of that. It's a fine tool for what it does. You don't have to worry about backing up checkpoints or anything, or sending around multiple drafts for revision and comment -- all of that is directly included. For people who need to manage versions, in order to use git you have to acknowledge that you can no longer treat your version control as an annoying little checkpointing thing that magically shares stuff, because that model ALWAYS breaks in reality; anyone who has used CVS knows this. Anyone who has had to do branching in Perforce or SVN knows this. You have to understand how it is implemented under the covers. Fortunately, git is really really simple under the covers -- there's no deltas or change records, just an efficiently stored snapshot of the entire tree, and when you commit a change, it stores an efficient snapshot of the entire tree. The previous snapshot is still there, as are all previous snapshots. Then it's just a matter of learning how each of git's commands map to changes to the underlying data model.