<p>If you want to keep these components in separate repositories, you still can, and create a new, separate repository, similar to a monorepo, to hold all of these components. Check out <a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules" rel="nofollow noreferrer">git submodules</a> or <a href="https://docs.github.com/en/get-started/using-git/about-git-subtree-merges" rel="nofollow noreferrer">git subtrees</a>? If you want to contribute back upstream from, you will want to use submodules, but your workflow becomes a little more complex. If you want to keep the same git workflow, and don't want to contribute back upstream, use subtrees.</p>

CC BY-SA 4.0
2024-03-04T19:32:16.673Z
2024-03-04T19:32:16.673Z
Preston Martin
<p>I'm a newbie into devops tasks. I am working on a project in which I have the following parts: One frontend which provides info about the project (1), one frontend that is the actual web application (2), one frontend that provides authentication logic (3), one backend for the web application (4) and one backend for authentication (5). Each of them will not communicate with all the others, however there will be communications like 2-4, 3-5.</p>
<p>Now, each of them lives on its own git repo. I am starting to dockerize it, and I don't know if keeping them in separate repos is the best approach. I feel like it makes setting up docker a bit more difficult as each service will be run from a different docker compose file.</p>
<p>For the first steps, I guess having a single repo would be easier, however I don't feel like that is the best approach if the project would become larger and larger.</p>
<p>Any opinions with regard to this topic?</p>

CC BY-SA 4.0
2024-11-29T23:28:19.217Z
monorepos are always a bad choice and you acknowledge it only after, when you want to scale. A little knowledge about git submodules can help you ace your project.
YassineLbk
<docker><docker-compose><monorepo>
Should I use monorepo for deploying projects?
Javier
# Should I use monorepo for deploying projects?

(Asked by: username_0 on 2024-03-04)

I'm a newbie into devops tasks. I am working on a project in which I have the following parts: One frontend which provides info about the project (1), one frontend that is the actual web application (2), one frontend that provides authentication logic (3), one backend for the web application (4) and one backend for authentication (5). Each of them will not communicate with all the others, however there will be communications like 2-4, 3-5.

Now, each of them lives on its own git repo. I am starting to dockerize it, and I don't know if keeping them in separate repos is the best approach. I feel like it makes setting up docker a bit more difficult as each service will be run from a different docker compose file.

For the first steps, I guess having a single repo would be easier, however I don't feel like that is the best approach if the project would become larger and larger.

Any opinions with regard to this topic?

**Tags:** docker, docker-compose, monorepo

> **Comments:**
> **username_1**: monorepos are always a bad choice and you acknowledge it only after, when you want to scale. A little knowledge about git submodules can help you ace your project.  

---

## 1 answers

### Answer by username_2 on 2024-03-04. Score: 0

If you want to keep these components in separate repositories, you still can, and create a new, separate repository, similar to a monorepo, to hold all of these components. Check out [git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) or [git subtrees](https://docs.github.com/en/get-started/using-git/about-git-subtree-merges)? If you want to contribute back upstream from, you will want to use submodules, but your workflow becomes a little more complex. If you want to keep the same git workflow, and don't want to contribute back upstream, use subtrees.


---

