That’s not a bad thing.  It simply means that it’s not any more or any less than what it claims to be: a distributed version control system.  And it’s very good at what it does.

But once you get beyond the initial repository setup and the standard add/commit cycle, you’re inevitably going to have a few questions:

• How often should I commit my changes?
• When should I create a new branch?
• What do I need to do to share my updates?

And these lead to a few more

• How do I manage all these branches?
• When should I merge the changes from my branches together?
• What’s the difference between a merge and rebase?

If you’re working in a team, you’ll probably also have

• What’s everyone working on?
• Do I have the latest updates?
• When do I submit my changes to the team?

And if you’ve been going for a while, you’ll want to know

• How do I simultaneously manage a release and a development version?
• Did that production fix get back into development?
• What did I just release?

At this point, you’re starting to slip into the realm of software configuration management (SCM).  Version control is just a small part of that.

The bad news is that Git doesn’t say anything about how you should do any of this (FYI, the pull request is more a suggestion than a formal required process even if it’s what Linus does).  It’s also the good news: You have all the technical capabilities you need but you’re not tied to a rigid one-size-fits-all process.

The key thing to remember is that Git isn’t the first VCS tool out there, even if it might be the first one you’re using.  There’s an amazing wealth of SCM knowledge to tap into.  It’s a matter of starting with what works and figuring out how Git fits into that.