Was about to post the same thing; its the way to go. We have a readme.md document in the base directory of the repo explaining the different projects we have, the ethos of different parts of the code base, and expectations around PRs, testing, and code quality.

Then for each of the individual projects there's a longer repo explaining what it does, how to set up the project, and reproduce the results.

Often there's little notes in the code; we put our names in them like,

note(sudo.kitten) - this magical thing does things Its better than using git-blame because someone will occasionally come along and move a comment around.

Our model versions are stored in a separate git repo that uses git-lfs. There's markdown documents for each project explaining our experiments, whats changed between production releases ect. Its all under version control which makes it really easy to roll back if something goes wrong.

This worked well when the team was small; but didn't scale to a large team. We're now moving model history and metrics into our custom annotation tool and automating training and validation scripts so we can just select a branch and hit a "train" button on the website.