We’re starting to develop many small web projects in our company, where mostly they will have one shared resource with some code pieces (SDKs, utilities and etc…)
Our team is small (~5) but is growing and is expected to grow x2-x3 in several months.
We’re discussing what would be the right way to build our source control and came up with 2 main ideas:
-
Put all code in one repo which will be synced with Github. Everyone
will have the copy of all projects and will have the shared
resources folder as well – thus will be able to pull/push the shared
code and the project code with only one action. Also, there will be
no need to follow multiple repositories. On the other side, this
might create confusion and errors – as all the code pulled/pushed
even if working only on one project. -
Put each project in its own repo and put the shared resources
project in its own repo. Thus everyone who is working on a project
will work only on that repo and won’t have to push / pull other
repos. This will create a more streamlined work – but will make
everyone work with at least 2 repositories (shared resources and his
project), which might create confusion.
I would be glad to know if one of the options is a bad idea or if there is a better way.
Thanks!
3
I’d suggest to create a new repository for every project. Aside from the fact that it is common practice, it is practical as well. One of the advantages would be that you don’t have to retrieve all projects, when you just want to work on a single project. A second advantage would be that everything files, branches, log-messages etc. are applicable to a single project, so you don’t have to dig through irrelevant information.
If one project is dependent on another project, you can use the git submodule functionality. Changes made to the submodule can easily be pushed to the central repository (e.g., GitHub) and pulled by the other projects, such that they benefit as well. Of course you can also create branches for the submodule, in case you have project-specific changes. More on submodules in git can be found here at the Git Submodule Documentation.
0
My team have taken a different approach to the shared resources issue, which is to publish it as a NuGet package and host it on a local network share. This has the advantage that when you update the shared resource with a breaking change, you don’t break the projects that depend on it. One small disadvantage is that it is time-consuming to make small changes (e.g. adding an extension method), but I feel the pros outweigh the cons
More information on that can be found on the NuGet docs.
3