I want to know how to manage a big project with many components with version control management system.

In my current project there are 4 major parts.

  1. Web
  2. Server
  3. Admin console
  4. Platform.

The web and server part uses 2 libraries that I wrote. In total there are 5 git repositories and 1 mercurial repository. The project build script is in Platform repository. It automates the whole building process.

The problem is when I add a new feature that affects multiple components I have to create branch for each of the affected repo. Implement the feature. Merge it back. My gut feeling is "something is wrong".

So should I create a single repo and put all the components there? I think branching will be easier in that case. Or I just do what I am doing right now. In that case how do I solve this problem of creating branch on each repository?

  • Can you re-arrange your functionality to place as much as possible in shared libraries (Ruby gems, Python eggs, Java beans, etc), and then assemble the parts with the idea of "composing" each element out of the libraries?
    – Narfanator
    Jun 11, 2013 at 19:04
  • Think about when we add a new protocol support on Server component. We must also add proper interaction controls (buttons, fields etc) for this in web too. Thats the problem Jun 11, 2013 at 19:29
  • 1
    That sounds like it's analogous to the "bridge" pattern; you might take inspiration from that.
    – Narfanator
    Jun 11, 2013 at 23:28
  • one repository to rule them all Jun 28, 2013 at 5:48

2 Answers 2


In the situation you describe, you are not getting any benefit from having multiple repositories, but you do have a cost: you can't roll back to an older version of a repository, and have any confidence that your system will continue to work. This is because your code is tightly coupled across repositories. As confidence in the ability to roll back is one of the main benefits of source control, this isn't the situation you want to be in.

The solution is to define your repository structure based on the coupling of the code within it: if project component A shares only stable interfaces with project component B, then they can be placed in separate repositories. Otherwise, they should be co-located in the same repository. A more granular repository layout will reflect a better factored system architecture.


If each of your repositories are stand-alone projects or libraries, then I'd say that there isn't anything inherently wrong with needing to create feature branches on each repo when adding new features that cross-cut across the projects. By being stand-alone, each one can be independently versioned and you can deprecate old APIs.

But in your particular case, it sounds like your repositories might not be grouping your code effectively. If changes to code in one repository requires changes to others (deprecation aside) then either your coupling is too tight or the repositories should be reorganized.

If all the repositories are really part of the same project (they can't stand alone) then maybe you should only have 1 repository. (Or maybe 2: the main project and one for generic/standardized functionality.)

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.