4

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:

  1. 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.

  2. 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!

Improve this question
3
  • 3
    Git repos are cheap – it is common to use a new repo for each project. Sometimes, multiple branches are used for different parts of the project (e.g. docs and code), although I frown on this practice. Handling multiple repos isn't that complicated after you've done it a few times, and I don't think there'll be much confusion at all. If you want to enforce a specific workflow, wrap the git commands into easy to use scripts.
    – amon
    Commented Aug 4, 2014 at 7:57
  • @amon - thanks :) How would you approach the shared-resources project? As it is needed for each project
    – roman
    Commented Aug 4, 2014 at 7:59
  • 3
    See a related question.
    – AProgrammer
    Commented Aug 4, 2014 at 8:02

2 Answers 2

Reset to default
4

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.

Improve this answer
0
1

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.

Improve this answer
3
  • 1
    Thanks :) But we work in a Linux env - so NuGet won't work for us.
    – roman
    Commented Aug 4, 2014 at 8:19
  • Ah I see. You could always script something up that compiles the shared project and copies the binary output to a shared directory? A shade more work than using a package manager but would achieve a similar workflow
    – Alex
    Commented Aug 4, 2014 at 8:27
  • Yeah - it's something like @amon suggested. Wrap it all in scripts... Thanks for the idea!
    – roman
    Commented Aug 4, 2014 at 8:29

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