First, I just want to say I don't understand why you are migrating if they don't want to use git like git.
I agree with you that it's workable, and it's not even that problematic to split it up later. You would basically just duplicate the monorepo and delete the branches you don't want in each copy.
The main concern I would have is dealing with the ...
Good commit messages are underrated, in my opinion, kudos to you for trying to improve in this aspect.
I think the primary audience for commit messages are other developers. There might be other stakeholders, but they also need to be quite tech-savvy to look into commit messages anyway.
With that said, you should probably start by defining a commit message ...
There can be several potential readers with different expectations:
A reviewer going over your code will read the commit message for context and to understand the rationale for the new code.
Your team (and that includes you) using blame or similar tools to understand when and why was a particular change introduced into the code base, either when ...
Is it possible to migrate an SVN repository that was once 2 SVN repositories to git while maintaining history from before the 2 svn repositories were merged
Assuming you still have the 2 svn repositories you can git svn clone them into 2 separate git branches and then merge them in git.
This would completely preserve history as you've always got the ...
To be honest, you wrote
This solution feels a lot better
for an approach which looked pretty horrible to me.
But first things first. I think the missing piece here is getting clarity about an appropriate versioning and release strategy - which is tool-agnostic. Then, as a second step, one can decide about the repo structure which supports this strategy ...
You should make every “branch” into its own repository.
While it might work like it is now (the technical details are laid out in other answers and comments) it will still introduce a lot of unnecessary complexity. Complexity means that it will be harder to onboard new colleagues, etc.
They have different release schedules.
This indicate that you should not have them in the same git repository.
These applications share some code
Move that into a shared library used by your three products, using the appropriate dependency management system for your platform. Put that in a separate git repository too.
So, four git repositories.
The answer can be very nuanced depending on a wide variety of factors (long answer in this article on monorepo vs polyrepo that I wrote). Regardless of whether you use a monorepo or a polyrepo, I would consider splitting the code into separate modules, where the shared code is part of one or more such modules. Then each of these modules could have their own ...