So your question implies to me that you have done very little with git before.. It would likely pay you dividends if you were to do some reading about how git works and maybe some general work flow concepts..
I realize that it's a little scary but I think (and in my experience) in the long term if you embrace this you'll really appreciate how it works.. you get a lot of stuff for free and it only serves to improve your end product.. Even php is entirely in github =)
With the typical work flow of any open source product, only direct team members can push directly to the repo or accept pull requests. (it's a setting in github).. Everyone else can fork the work or issue pull requests back to your repo, but they don't have access to modify files without your permission. They can't push directly into your repo, but rather have to issue a pull request that must be approved first.
So for example;
I find a bug.. I fork or clone your repo and fix the bug.. I then issue a pull request back to your repo..
You guys have a look at the code submitted by me in the pull request and make sure it conforms to coding standards, solves the problem at hand and doesn't inject malicious code or cause other headaches..etc.. You can either accept the pull or reject it.. If you accept it gets merged into the repo just as if you pushed a fix yourself..
If you reject it you can add a note to the rejection as to why the pull isn't up to snuff.. And that can be anything from "I don't like you" to "we are fixing this differently".. to nothing at all.. though its generally polite to say why a pull got rejected.
If you go one step further you can put all of your issue back log into github that users can browser and submit fixes for directly.. so I can say "This pull request fixes issue #1234" and you can then see exactly what it fixes and close the ticket too..
An added bonus is that every time you tag a repo to a version number github automatically creates a zip archive at that very moment of the latest branch on master that you can link to on your website.. no longer do you have to host and manage zips or tgz's but github does it for you..
For now would I would probably do if I were in your shoes is to create a master branch with the core code.. create a development branch that you do all your pushing to and test on.. when its "ready" tag it and merge that into your master.. master is the code on the website for download.. The develop branch is the ongoing unstable branch..
Then you create feature branches for any new features you want and merge those back into develop as they get done..
Bugs are either fixed directly in the development branch or in a hotfix branch that gets pushed to master directly.. but lets not get too confusing yet =)
Unlike svn everything in git is a branch and branches are good.. (unlike svn in which branches and merging can suck..)
Either way you should likely try forking a big open source product and then get a buddy to create an account and have them issue a pull request that changes the "hello world" to your product and see how it works.. its all free and it's worth your effort to learn how this works. This work flow is very important and will make you more comfortable with this process..
