Best practices for non-software org?


I am part of a hardware startup that is growing and we are starting to get serious about code and version control. Previous to this most code lived in a shared drive which I know is a big no-no. When I say code I mean things like python scripts to implement physics models for various analyses, code to run data acquisition hardware for experiments etc. We are not a software org so software is not our primary product but rather software is used to help develop our product. I have been tasked with helping bring some order and control to bits of code that is sort of everywhere.

My initial thought was to create a few high level repos like “engineering” and “R&D” and have basically everything live in those. While I am finding it hard to find good best practices for non-software orgs, I am reconsidering having such expansive repos and maybe moving more to a “{org}-{project}” structure like “eng-designtoolX” or “rd-physicsModelY” type structure. Does anyone have suggestions or know of any resources on how best to approach this organization problem? I don’t want to have a million repos with 1-2 files each in them but at the same time having 1-3 expansive repos might defeat the purpose of git a bit.


I suggest creating a GitHub organization in any case.
Then you can decide using a Monorepo inside this organization to group multiple related projects.

But it’s hard to recommend you a specific naming or structure strategy without having your knowledge.

Thanks for the reply! I have already created a github org for us and was planning on using that as the owner of all repos.

I totally understand it’s hard to give specific suggestions without knowing our structure. I was maybe hoping someone had some knowledge of blog posts or any other resources that discuss pros/cons to different strategies. I am finding it actually surprisingly difficult to find information on that topic (primarily because most info on this type of topic focuses on software products)

In general, creating repositories for organizational units doesn’t work well. In most cases a repository should contain things related to one project or subject. For example if you’re writing books, have one repository per book, not a “books” repository. Of course what fits together may be a bit ambiguous, too. :wink:

Yeah that’s why I am leaning towards the second structure of having {org}-{project/module}. I am just worried about having like 50 repos with a few files each but maybe that is still preferable to having a giant monolithic repo.

The following compares the mentioned Monorepo vs the default way (polyrepo):

Thanks for that resource it was very helpful!