I have a Visual Studio solution with multiple projects:

  • Acme.Core
  • Acme.Core.Tests
  • Acme.UI.MvcSite1
  • Acme.UI.MvcSite2
  • Acme.UI.WinformsApp1
  • Acme.UI.WinformsApp2
  • ...

The entire solution is checked-in in a single GitHub (private) repo. Acme.Core contains our business logic and all UI projects are deployables. UI projects have different requirements and features, but some of them are implemented in more than one project.

All issues are opened in a single issue tracker and classified using labels ([MvcSite1], [WinformsApp1], etc) but I'm thinking it's starting to get messy.

Is it ok to use a single repository and issue tracker to track multiple projects in one solution?


3 Answers 3


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.

  • Either you do a git revert to remove a single commit or you rewrite history. If instead of doing a git reset (as I think you mean with rollback) you do a git rebase -i and just remove the faulty commit. You've solved the problem of wiping out changes to other parts of the project. You're fine as long as you don't have unrelated changes in the same commit.
    – iveqy
    Commented Oct 31, 2013 at 7:44
  • There's scenarios where it could become a lot messier than just reverting a single commit, and rewriting history can be very dangerous. For instance, what if a faulty piece of code propagates through multiple commits, or a large amount of work is dependent on such a feature? Speaking from personal experience there, but maybe it's an edge case.
    – DaveWeber
    Commented Oct 31, 2013 at 13:49

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?

  • 2
    What does the organization of an IDE/build have to do with the number of repositories and issue trackers you have? You can still fit into the IDE model with multiple repositories as submodules, for example. Commented May 2, 2013 at 11:41
  • I never said you had to, nor was the question that deep. He had a pretty simple question -- "Is it ok to use a single repository and issue tracker to track multiple projects in one solution?" -- that didn't need a philosophical answer. Also, in most visual studio specific cases the stu modules were their own solutions more than a single included project. Commented May 2, 2013 at 11:45
  • 3
    An answer should answer the real underlying question and demonstrate some actual experience or common practices. A simple "yup/nope" with some non-applicable rationale isn't a quality answer. I'm sorry, but your answer contributes nothing to the actual underlying question. Commented May 2, 2013 at 11:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.