Re-using the issue tracker should be fine, as long as you’re tagging the issues properly so that it’s easy to differentiate between projects.

Re-using the same repository is more convoluted. The advantage to this approach is removing potentially extravagant merges. On the other hand, it may become more difficult to deploy to test environments unless you can push branches out. Maybe the worst case I can think of in that scenario is if you introduce a major bug in one project, and while resolving it, require a rollback that wipes out changes made in other projects. I would think your best bet is to compartmentalize your code as best as you can and use separate repositories.

Git doesn’t scale. Git is fast, and awesome in handle huge repositories, but it doesn’t scale very well. Therefor most projects using git has one repo for each project (not like svn where you can have one repo for the whole company and then have one path for each project).

The one project-one repo is quite fundamental in git’s design and hence github is also built with the one project – one repo in mind.

It’s of course fine to have multiple projects in one repo, until you hit the ceiling. If you think your bugtracker is too confusing and you rather treated the projects separately, then you’ve hit the ceiling and you really should divide your repo to one repo for each project.

You should probably look closer into git submodules (the pro-git book has a chapter about them) then you want to read up on git filter-branch on how to divide your current repo.

If I understand your enviroment correctly you would benefit from the power of submodules, that will make you able to do complicated configurations.

Certainly — why would visual studio’s fundamental unit be a solution if this weren’t the case?