Should frontend and backend be on separate GitHub repos?

Question

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).

Answer 1

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.

Answer 2

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.