20

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.

double-beep
  • 5,031
  • 17
  • 33
  • 41
Hubro
  • 56,214
  • 69
  • 228
  • 381

3 Answers3

21

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.

Brian Guthrie
  • 2,818
  • 2
  • 19
  • 13
  • How would you recommend keeping them in the same repo? Is it difficult or otherwise a bad idea to keep them as two different branches? – Hubro Jan 20 '12 at 07:04
  • 5
    Branches are useful when you need to create divergent versions of the same basic codebase, so they aren't a good fit here. For now, separate directories in the same master are probably the way to go. Organize them in whatever way makes sense to you, maybe as two separate directories but I'd treat them as the same basic project. – Brian Guthrie Jan 20 '12 at 07:25
  • I agree with you. However could you explain why most github repos I've seen tracks documentation as it's own branch? – Hubro Jan 20 '12 at 07:51
  • 1
    @Codemonkey github offers the posibillity to create custom project pages by placing them into a `gh-pages` branch. See http://pages.github.com/ for further details. – Rudi Jan 28 '12 at 14:36
  • @BrianGuthrie so a client mobile app and web app would qualify for being 'multiple interfaces' right? – Raunaqss Dec 14 '17 at 06:43
8

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.
fyr
  • 20,227
  • 7
  • 37
  • 53
7

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Could you comment on why it's normal to put documentation in a branch of a project? – Hubro Jan 21 '12 at 22:20
  • 2
    @Codemonkey The orphan branch technique used by some GitHub projects can be a nice way to: a/ avoid creating a separate repo for a set of files (the documentations) which is still fairly related to the main set of files (the program it documents), while b/ having a different lifecycle (not updated at the same time than the main program, which evolves at a different pace, in different branches). See as other examples of orphan branch usage: http://stackoverflow.com/a/7648343/6309 or http://stackoverflow.com/a/7411758/6309 – VonC Jan 21 '12 at 23:03