You don't really have to understand the data structures any more than in any other VCS.

If you're on Subversion and ignore that the repo is basically a counted list of big file trees with properties on the nodes, you won't get branching right.

If (FSM forbid) you're on MKS and ignore that it keeps per-file version histories somewhere in the belly of the expensive server, you'll try silly things like creating new files on a branch.

And for Git, you learn that there are commits, trees and refs.

> But why do I have to understand its data structures?

You don't. But if your mental model of how Git works is wrong – and if you came from another SCM system, it probably is – figuring out how Git actually works is the only way to fix it.

You don't have to if you don't want to. But it's by far the easiest way to understand things. It's not actually complicated.

The whole point of git is the weird database. I'd tell you to go use another system if you don't like it, but that's not really an option anymore. So I'd instead just suggest that you do yourself a favor and spend an hour learning about it; you'll be far more effective as a result.

You don't really have to understand its data structures to use it but, as with anything, having a more accurate mental model of the tool is a great help in figuring out how to achieve your specific aims.

Git isn't an SCM, it's a SCM building toolkit.

You personally do not have to understand all the parts, but you do need someone to build a SCM for you out of it and tell you what the parts are then.

That was the original value proposition made by Linus when he first create Git. This was largely out of necessity because it all happened over a very few short days in the panic of losing BitKeeper support for the Kernel.

However it is no longer true. Git is very much a SCM and is being developed as an independent tool, not just as a platform for tool development.

And still, Git, compared to most centralized VCSes, forces you to consciously design the versioning workflow. Where will the repositories be, who pushes where under what circumstances, what repo makes the golden releases, will you merge the upstream into feature branches or will you rebase, all that.

That makes it harder to introduce Git in an organization where nobody brings along enough Git experience to design all that upfront.

Just grab the gitpro book and spend 3 minutes copying one of the diagrams and the description (or use the website).

I understand what you're saying: I have helped some friends who were that guy trying to bring it in.

It's easy to use Git in exactly the same way you would use SVN with a single central repository.

Looking into what you said, that is what happened.

I'd always heard that said about the tool we used today to point out "It does way too much for a single SCM, you have to find what YOU need a SCM to do and use that".

If you don't need anything that it's offering, fine, don't use it.

I need lots of branches amongst my team. I tried to use Perforce branching and I found out I was pounding nails into my eyeballs.

I'd be surprised if any of the other SCMs that can do what git does have significantly different models of behavior. I know Darcs is quite similar (though it can be a little smarter about merges sometimes).

The git model seems to not try to abstract away the details of the backend but rather give you tools and shortcuts to do common operations on it. As a result, the answer to "can I do this with git" is most often yes. But that comes at the added cost of having to know what's going on.