GitHub Repositories – Should Frontend and Backend Be on Separate Repos?

gitgithubWordpress

We are new to git, but this fundamental question needs to be sorted out before we can begin. It's two devs who have been working standalone for a while. Now the time has come to adopt git (at the first sight of sending each other zips and poking the same files). I work on both front&back, he works only on the back. So teamwork only happens on the backend. It's a WordPress plugin that currently has a standalone backend and a frontend and they are installed separately. (Commercial, so no SVN here.) Obviously they will be merged into one, especially for production/release. What's the best practice here? My ideas:

  • A. 1 repo that clones into the /wp-content/plugins/ folder of our dev WP installations, ourplugin-front and ourplugin-back then .gitignore any other folders from plugins. One day when we are ready to forge the two, we'll just create a common ourplugin folder and move the files there.
  • B. 2 repos, one for each side. Eventually one side will get abandoned when its files begin existing on the other one. We'd rename the winning repo, while losing versions/history of the transferred files.
  • C. 2 repos, but combining the actual repos once we no longer work standalone. Since I'm new to this, it might be a clusterfck but I read that it's possible. Or we could decide what we want now and avoid this as it'd turn into A. anyway.
  • D. 2 repos. Combine only at production build and do not store the built/combined version on git at all. Not sure what tool would pull from 2 repos, build, and combine things into one. Sounds fancy. Would need to keep the front up to date for the backend guy on his machine though (scheduled git pull or something).

Best Answer

There are two main considerations for deciding to use one or two repositories:

  1. Will it hinder or aid the development of the front-end or the back-end if the other is also present in your dev environment? This is something that depends heavily on your development process and cannot be answered by us.

  2. Is it the intention to always release the front-end and back-end together under a single version number or is it possible they will start to follow different release frequencies with diverting version numbers?

    Having independent release intervals is a clear sign for using separate repositories, while releases in tandem are easier if everything is in a single repository.

If you can't come to a decision now, I would recommend that you start with separate repositories, because it is easier to merge repositories later on than it is to split them.

Related Topic