Is a fork-per-developer approach appropriate in this case? It seems like it could be a little overkill. I'm not sure that we need a fork for every developer, unless we introduce developers who don't have direct push access and need all their code reviewed. In which case, we would want to institute a policy like that, for those developers only. So, which is better? All developers in a single repository, or a fork for everyone?
Depends on your team's scale, I guess. I used to work in a small team where we just had a single repo and features got their own branches within that repo. That worked just fine for us.
However, I now regularly contribute to a larger open source project where a few dozen people have access to the central repo. We still do all major development in personal repos and submit PRs for features so code can be reviewed, although bugfixes can be pushed directly. The main repo only carries master and release branches, keeping it free of clutter. Feature branches are in personal repos, so they can still be seen by others (making early PRs for them will alert others in the team that work on a feature is underway). I can recommend this workflow for any project with more than a handful of developers; the only downside to it is having to work with multiple remotes.
I think you are doing great by splitting your Visual Studio Solution into several Projects that are creating libraries - as you and @antlersoft said in the comment.
This way you can have several other Solutions or even projects that create a standalone binary (like command line exe) referencing these library (Solution Explorer: add reference).
The one thing that git or Visual Studio is not doing for you (as the software architect of one or several solutions) is to untangle the references back and forth between your modules (I use this synonymous to library here).
It is a good idea to have a layered architecture in every bigger software system. When you go and re-architecture your whole system, you can follow these best practices:
- create a namespace for each library that spreads across all the source files in this library
- check the usage: which .cs file (and therefore it's namespace and the library that is compiled as a separate project) uses the class(es) in this library
- assign every namespace/library to one layer (you don't have to give names to the layers); you could do this on paper or use any UML tool that supports component diagrams (including the one in the higher valued Visual Studio Versions; some UML tools call it explicitly layer diagram)
At the end of the day, a good architecture is achieved if no library of a certain layer is using any library in a layer above (no upwards pointing arrows) or the same layer (sidewards pointing arrows). If you can't get this done easily you can go for the weaker form of allowing same layer access.
{ If you download the preview version of Visual Studio "15" (which is a ultimate VS; as long as it is still available) you can open your project and pick New Diagram from the Architecture menu (right next to Tools), chose Layer Diagram and play a little bit around - there is a how-to video linked after you created your first diagram. The following screenshot shows the generated diagram that you get when you drag in some of your libraries from the Solution Explorer, right-click on it and select generate dependencies. }
The following refactorings help you getting there:
- Move a whole class to a different namespace/library
- move a property/field up or down the inheritance hierarchy to move the dependency that originates from accessing this property/field into a different namespace
- move a method up or down the inheritance hierarchy for the same reason
- do some additional classification by a) adding a more general superclass that contains only the a subset of the properties/fields and/or methods or by b) creating more specific subclasses
The process of re-architecturing or refactoring your system to resolve inter-library (package/namespace/module) dependencies that prevent you from reusing your existing software in additional projects has produced a very significant amount of publications. I called it untangling above which is not really the scientific term. One outstanding book reference that covers this (and was written way before git times but is still a very good source) is the Gang-of-Four Book which uses the term software design (as in object oriented analysis and design). You can also find some very good books or articles using re-architecturing or just architecture or refactoring in your favorite book store or search engine.
Just to reconfirm again: once you re-adjusted the project lines this way, each project is a good candidate for also being used as a git repository and you can check it out to any number of additional solutions you want to reuse this library in.
Best Answer
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.