Php – the best setup for distributing a PHP application

Been through this before. Actually still living in it. You've generally got a good idea of where you are heading -- most folks doing this barely use source control. Alot of exactly what to use depends on which stack(s) you use. Can you share that?

Anyhow, running down your list:

1. SCM: really depends on environment. If you are on windows, Mercurial tends to make a lot more sense as you aren't a 2nd class citizen. I would seriously consider using a hosted solution here if your software isn't too top secret and you've got solid bandwidth to take advantage of it. One other side to this -- SVN isn't really that bad in internal scenarios where you know you have connectivity and central control make sense. And it has the advantage of being much easer to grok for the uninitiated. I can get my art department to somewhat use SVN. Good luck with git.
2. Bug Tracking/Documentation: I'm lumping these together because I'd generally contend you want them in the same system. For small teams, the best choice IMHO is Redmine (or Chili depending on which fork you want to back). They both handle bugs and do wiki/discussion type stuff. Moreover, it is easy to link from bugs to the discussion or wiki and vice-versa. They can also easily take tickets over email and hook up to LDAP, which makes it pretty easy to get your end users submitting trackable tickets rather than random emails to the wrong person at 2am on a sunday. Oh, and it will talk to your SCM too.
3. You didn't mention Continuous Integration but I'd argue that is perhaps more important than anything here but source control -- it keeps you honest. To some extent what to use depends on what you are building, but in general the best option out there IMHO is TeamCity. The free SKU probably works for most internal uses as 20 projects and users is typically more than enough. The beauty of it is it is so disturbingly easy to setup it is scary -- you can go from zero to continuously integrated goodness in 5 minutes. 4 of which are spent watching the installer go.

The other angle here would be to ask your developers what they want to use. Or setup some sort of slushy tools fund budget for them. New stuff pops up all the time and it is very, very app/platform/language specific what people want.

The advantages git has come from tossing out a lot of old assumptions about what a VCS should do. The disadvantages git has come from not being able to leverage prior experience and not being able to do things the way you are used to.

If you are going to switch from something else to git, try to start tabula-rasa (though it is impossible to truly do in practice). Evaluate it based on what it does and how well it does it, not on how it does it compared to how you are used to doing it. It's not that you expect too much, it's that your expectations are orthogonal to what git provides. If you're married to GUI operation, you'll be disappointed. Git does have gui tools available, but they don't add much. That's not a failure to provide them so much as there isn't that much that a gui can add. GitK does help, not in day-to-day operations, but rather in visualizing the branch structure and examining or searching history.

Here's a goofy analogy for what I mean by "orthogonal". One of the things you can do with a newspaper is wrap fish in it, or use it to line a birdcage. But those are not essential to the function of a newspaper, those are incidental features of the form it comes in. Expecting git to "check in files", or "allow you to select projects", or provide a "connect to..." is kind of like expecting to be able to wrap fish or line your birdcage with a newspaper's website.