Git repository: Split or Not
As a software developer when you start a new project or product development, you have to decide about your Git repository’s structure! especially if you are building multiple parts: frontend and backend (API). (sometimes you have multiple API, batches …)
During my last year’s experience, I have seen two possibilities :
- One Repo for all (MonoRepo)
- Multiple Repos (one for each part).
To be honest, until now I’m not sure which option is better :) I will try to give some hints so you can decide your path.
These hints suppose you have a team working in an agile way and adopting DevOps practices ( with continuous delivery applied )
‘ One for all ’ is better for you when :
You are a small team with full-stack developers : no need to split and make developers’ life hard. you will have one CI/CD pipeline and developers will push once for each feature.
You choose a monolithic architecture, so in general
You need an easy way to coordinate changes across modules.
You need to manage one CI/CD pipeline for all parts
You need to do cross modules testing, which lets you find bugs early
With lots of repos, making cross-repo changes is painful. It typically involves a lot of manual coordination or scripting
With a monorepo, you just refactor the API and all of its callers in one commit
A lot of company like Google, Facebook, Twitter, Digital Ocean are using monorepo strategy , for sure it’s due to some good reasons ;)
‘ Multiple Repo ’ is your choice if :
You have a big team organized in features-teams way, every small team is delivering one API/microservice independantly
To avoid having big repository size
Having one big repositry will force all teams to trigger all your pipeling job/steps even if they’re not changed!
You need to manage access control : not all members can see other team’s code ! it’s not a usual case, it may hapen ;)
As I said before, there is no absolute truth! even if all big GAFA are using MonoRepo, you need to decide yourself … and don’t worry, moving from one option to the other is not impossible … Generally, I recommend starting with the MonoRepo strategy to keep it simple and then split if you find it hard to manage and more efficient with multiple repositories.
Refs : http://danluu.com/monorepo/
