Parent is downvoted but this seems like a valid question to me. The interface consists of git sub commands and their flags. One could argue that there are too many flags, or even too many commands, but why not offer flexibility when you can as long as you keep sane defaults?
I think that git commit, init, add, fetch, branch, checkout, merge, and push all have sane defaults and anybody can pick up very basic git usage using those commands in less than a few hours.
Things get complicated when you start looking at the details, but I don't see any way around that. And the interface doesn't change. It's just a matter of learning more flags and commands.
I have tons of little problems with it that would be silly to enumerate, but they fall into 3 broad categories.
1) Terrible tab completion support.
2) Multiple command/option permutations that do nearly the same thing with small subtle differences.
3) Lack of cohesion amongst the community around best practices (especially with regards to branching/merging/rebasing).
Each git command seems like it was done by its own subcommittee without regards to what the other commands do. Functionality overlaps. Mnemonics from one command don't carry to another. I forget the specific example, but one command would be colorized with command line options, and another would be colorized with environment settings.
I'll admit it's a little bit strange, but it's not like you can't just alias frequently used commands that are more complicated. Besides, Git's utility makes up for this by far.
Then again, I alias nearly all the CLI programs I use frequently. Grep's recursive search is aliased to `sr`, Python to `py`, Django's `manage.py runserver` to `run`.