Git – Two code bases in one repository… is there ever a good reason to do this

gitrepositoryversion control

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.

Best Answer

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.

Related Topic