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).
  • 2
    it depends but you are always safer with more repos rather than less
    – Ewan
    Commented Oct 15, 2020 at 9:03
  • If you're looking for more info on the subject look into the pros and cons of the monorepo, that's the keyword you may be missing
    – JayZ
    Commented Oct 15, 2020 at 12:11

2 Answers 2


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.

  • Actually, with the right tools - e.g. git subtree, git filter-repo - both splitting and merging are pretty easy.
    – IMSoP
    Commented Oct 15, 2020 at 13:15
  • 3
    @IMSoP, I am not concerned about the git side of splitting a repository. It could even be done by cloning and then removing the unneeded parts. The problems lie in the content that may have gotten shared/interwoven between the front-end and the back-end. And that is not just production code, but also tools that help in the build process. Commented Oct 15, 2020 at 13:50

You may want to check monorepo(single repository) or separate repositories.

When you have Monorepo:

  1. It is easy to keep your backend and frontend versions the same.
  2. Have atomic commits.
  3. Centralized CI/CD(when you have centralized CI/CD it will be more complex to configure. Because It is harder to separate frontend and backend CI/CD pipelines.)
  4. When everything is in the same repo they might be highly coupled.

Separate Repositories:

  1. Clear Separation of Concerns.
  2. Sepereted CI/CD so easy configuration
  3. harder version matching
  4. you have 2 repos to manage it is more work.

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.