We currently use subversion but are planning on moving to git.

We currently have 3 separate repositories, 1 for a restful service, the other two for two front end applications.

All 3 are deployed separately and can change independently for bug fixes/enhancements.

My question is should they remain as 3 separate git projects or sit as folders in one parent repo?

If we go for one repo do we have to redeploy all three if one changes.

If you make seperate releases of each part, they need to be separate git repositories.

Git submodules are pretty simple but might be even better to tie them together with a package manager related to the contents. Composer? Npm?

Rachel

There is no right answer to separate Vs one massive repo. We’ve gone the separate route for the big solutions and a shared one for the smaller solutions.

If using shared no you wouldn’t need to redeploy all if only one changes.

I’d say it more depends on your release and deployment process. Is that tied to one approach?

From an purely logical, organisational point of view, I’d use separate repos. And, I’d make sure the release and deployment automation is driven from separate repos.

That said, the mono repo approach is used by some of the massive companie. I believe Facebook and google have one big repo. I read an article a while back outlying the pros and cons but it didn’t speak to me and our team. They had to write a lot of tooling themselves to make it work.

I’d say it more depends on your release and deployment process

This. If they’re 3 entirely separate codebases then I don’t see much of a reason to not go for 3 repos though. Unless you have a good reason to go monorepo then I wouldn’t.

I’ve read the same about Facebook and Google having mono repos.

We could use a mono repo as our projects build into nuget packages. However we give clients access to the planning boards for bug tracking so tend to have repos for each client with their custom bits in.

Cheers, OP here.

Before I wrote this I leaned towards a single repo, but think you’ve changed my mind.

The deployment process is a manual crap process at the moment so linking and automating the three builds is the way forward I think.

Mad Bill,

For the automation piece I can high recommend the CI/CD tools that GitLab have built. In fact, GitLab is a great project.

We use an In house hosted version, their basic, which is free. I use their cloud hosted version for personal stuff. Also free. Their biz model is to allow free access for small teams/companies and add pay for features relevant for bigger codebases. We love it. Also, issue tracking, wiki, and the like for each project

Not gonna side one way or the other, but do understand and choose between sub modules and sub trees if going that way.

Google have some tools (scripts?) that manage nested Git repos – a guy at work was looking in to using them.

From your original description I’d go with a repo for each code base plus one for a build/release system. That is what I did at my last place – it was on Linux so the build system was really just a set of Bash scripts: clone_all, sync_all, build_all, build_X, etc. The sequence was to clone the build system then run “clone_all” which created the subdirectories and cloned the repos in there so the other scripts knew where things were. Nothing complicated.

Many repos means many merges (depending on how you branch within them: master-release, master-test-release, etc); this is where the pain is once you have many repos.

Separation of concerns. Small units of code, separate repos. Far more flexible and easier to manage, especially with multiple people working on components at the same time (less merges if fewer people are working on an individual repo). A bit more work with releases and deployment if they integrate into a larger product.

Git in particular is aimed at splitting into small projects. You can create git repositories anywhere out of any folder really, which is the beauty. You don’t even have to push them anywhere. Just create a repo on some folder and you’ve got instant version control. When good to go, push it to a more central server.

Also makes Continuous Integration faster. Quick to check-out, build and run unit tests. Result fed back to GitHub or similar if using something like that and set up all the integrations with your CI system. Means you can do pull requests, code review and the commits are automatically built and tested, and only then will it let you merge if all passed, if you set it up that way.

Worst thing about SVN is the common structure of one massive repository full of loads of projects and then a pain in the arse to work on one bit resulting in partial check-outs or checking out the whole lot. Then when it comes to migrating to Git and you just want a single project from the whole SVN repo, it gets very difficult. Made worse when someone decides to check in massive binaries into the repo!

I hope to never go back to SVN. Hate it.

Anyway, submodules are possible but are fiddly. Package dependencies make more sense. A good CI system can be set with dependencies so it will rebuild what’s necessary.

this is where the pain is once you have many repos.

Depends on the relationship between them.
You can certainly have way too many repos and then it gets seriously painful just keeping the damn things tidy. However having everything in one can be an arse in its own way.
Depends how tightly coupled everything is.
I would say the more important thing is the build tools alongside it. Lots of really nice convenient tools which take a lot of the pain out of either approach.

I would go for multi repository too.

I have just moved to mercurial from git. Very similar but works better in our group down to the rename command. Part of our project is PLC code and the standard is to constantly rename the file. This is so much easier with mercurial and keep version history. Integrates well with rest of the team.

Google have some tools (scripts?) that manage nested Git repos – a guy at work was looking in to using them.

Perhaps Android repo ?

It’s a bit like git submodules, but you configure everything with an XML file. It’s what gets used for android, but you can use it for anything.

I personally find it easier to use than git submodules, but I think that’s mainly due to laziness on my part.

In addition to having various bells and whistles (e.g. integration with code review tools, which you might well not need) the big difference is that with repo you can let a sub-repository be just the latest HEAD revision. With git-submodules, you have to be explicit about the version.

That then leads to more work – with android-repo you can just commit+push a change in a sub-module and everyone else then sees it. With git-submodules, you can commit and push your change but until you also push a change to the top level repo, no-one else will see your cool new warez.

This can be both good and bad.

As to multi-vs-mono – if you go the mono route you will get loads of sneaky dependencies between sub-modules, which will be a royal pain to remove.

I hope to never go back to SVN. Hate it.

Wait until you try Perforce….