I work on two code bases that are related, but independent. One is written in PHP, the other is Node JS. Currently, they are in a single repository. The repo is deployed to Heroku for the Node code, and a different hosting provider for the PHP code. I didn't set up the repo, but I now maintain the applications.

Is there any good reason that these code bases should be in the same repo? Would it make a difference if they were in the same language?

PS - the code bases are related but do not share any dependencies, even the databases used are different.

  • 4
    Languages are unimportant. The question you need to ask here: how related or independent are those two codebases? Any version dependencies? Any common components used? Are these codebases from two completely independently usable products?
    – Doc Brown
    Commented Nov 21, 2017 at 11:07
  • Ideally, you wouldn't have two versions of the same program, but of course life isn't ideal. If you must maintain both and it is causing you difficulty because they share the same repository, that's a reason to split it. Otherwise, as they say, if it ain't broke, don't fix it.
    – Neil
    Commented Nov 21, 2017 at 11:09
  • @Neil: where do you read "two versions of the same program"? I think the OP meant "two different programs".
    – Doc Brown
    Commented Nov 21, 2017 at 11:52
  • 1
    Do they evolve toghether? If not then they can be separated in different repositories. You could also (when using Git) create a base repo that references the other 2 as sub-repositories and manage them all together if necessary for any reasons. Commented Nov 21, 2017 at 12:22
  • @DocBrown Oops. Not sure how I got that impression.
    – Neil
    Commented Nov 21, 2017 at 12:40

1 Answer 1


The previous project I worked in grouped a lot of different languages and services in the same repository and provided a Vagrant box which provisioned a complete development environment from this.

This meant that all external pages, client facing APIs, internal microservices and so on were accessible from the get go. It just took two commands to get a new developer a workable set of services to start coding away. As Doc Brown points out in his comment it's very important how related the code is. All of the services in this setup were strictly interlinked and unusable without each other - That's not to say there couldn't have been other reasons to split the code base.

Most definitely separate repositories shine at times. The biggest reasons I can see off the top of my head;

  • If you want to strictly limit access - Perhaps some users are not supposed to be able to access certain applications/languages/code
  • Different people work on the different code bases and they have no relation to each other
  • The size of an individual language/code base/application is big enough to warrant it
  • You start building and utilizing internal/external package repositories - I strongly believe that you should have one repository per package/module you distribute with repositories

With this said, for most in-house development projects where everyone can or should be able to access all the code and no fancy deployment processes are needed a coarser approach is fine. In my current project we've divided the front end and back end code into two separate repositories since there are distinct groups working on their separate sides.

I think the best guiding advice I can give is:

Use one repository until you have a reason to divide the code base into multiple repositories, then ask yourself again if you really have a reason to divide it.

In your case there seems to be reason to divide the repositories but if neither of the above bullet points above are satisfied or it's making you unable to sleep at night I'd strongly advice against splitting the code up right now.

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.