Home » Nodejs » Is it a good idea to keep separate projects in the same repository if they are intimately related?

Is it a good idea to keep separate projects in the same repository if they are intimately related?

Posted by: admin November 29, 2017 Leave a comment


I’m in the early stages of a web application that will contain a client side JavaScript application that is deployed to the client’s browser and a server side REST type API that will reside on my server. The two will communicate using Ajax and JSON data.

Now here’s the thing; they are being developed completely separately, not even sharing one line of code or one resource. Both are node.js applications. The server side uses express and sequelize for all the server side stuff, and the client side is developed using hem development server with stylus and coffee-script and will be compiled down to 3 files (index.html, application.js and application.css) that will ultimately be deployed by the server as static data.

The part I’m uncertain about it how to version control this. Should they have shared or separate version numbers for instance. Also how should the git repo look. Is it common for a git repo root folder to contain two or more folders with separate but intimately related projects? Or should I separate them by branches, one called server, one called client? Or should I split them into two separate repositories altogether? (This would be more expensive as I’m using github private repos)

I’m not looking for anybody to tell me what to do, but inform me of the pros and cons of the alternatives. In your experience what would be the best course of action and why. Please feel free to also suggest other courses of action if you believe them to be good ones.



The general rule of thumb is, “things that change at the same time should be versioned together.”

If the backend needs to support multiple clients and will change independently of your frontend, as it would if you were going after a services-based architecture, then it’s worth thinking about separating these things into separate projects.

However, since it sounds like these two projects will be fairly tightly coupled, and your web application only makes sense with both in place, I’d suggest that you start by keeping them in the same repository. It’s a lower-friction development experience, and you can always split them up later if it gets to be painful or if separate teams need to work on them.


Branches are for making parallel versions of a common code base (see “When should you branch“).
So it is not a good fit for keeping track of two different, but closely related, modules.

Simple directories within your Git repo will be enough, and will ensure that any tag you will set on that repo will reference both modules.


From my point of view i would split client and server in two main folders under root. There are several reasons for this:

  1. Client and Server releases will relate(physically) to each other. As they do anyway beacause your client will heavily related to the api provided by your server software. So if you tag the repository as release you will be sure that both artifacts work together smoothly.

  2. You will have less pain to implement heavy integration testing as well as rolling out a continous integration infrastructure. With the other options it is also possible to bring this in in place but you will have to provide more overhead.

General branch usage:

  • the master is usually used as a consistent stable “snapshot” of your application (including client, server)
  • a branch may be used to represent a new feature development. Usually they are used this way. So you may end up having 1..n branches containing additions to your software. Which will be merged back to your master if you feel happy with it.