Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Please DO NOT cross post questions. It robs the community of the chance to contribute and learn from the other answers presented. I have flagged your question for mod review and potential merging. – GlenH7 May 2 '13 at 11:43
Please don't cross post. If you want the question migrating flag it. – ChrisF May 2 '13 at 11:43
Sorry for the mess and thank you for closing the question at StackOverflow. I cross-posted because I had no responses there and after some thought I realized that the question was more suitable here. – Luiz Damim May 2 '13 at 11:56

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.

share|improve this answer
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 Oct 31 '13 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 Oct 31 '13 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.

share|improve this answer

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

share|improve this answer
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. – Lars Viklund May 2 '13 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. – Wyatt Barnett May 2 '13 at 11:45
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. – Lars Viklund May 2 '13 at 11:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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