4 ms·
When you say "start your company", I assume a small total repo size. I would say definitely go for a single repo, every time, all the time. Internal version dep
by asmosoinio 9y ago
When you say "start your company", I assume a small total repo size. I would say definitely go for a single repo, every time, all the time. Internal version dependencies can be surprisingly hard to handle even with a handful of components/apps.
It is extremely unlikely that your companys code size would become too much to handle in a single repo. And before that, imho it's just premature optimization to split things up.
- philipov 9y agoWhile it's possible for it to become premature optimization, there is a level of division that hits a sweet spot that should absolutely be done up-front. I think it is not unreasonable to have a repository per project, and have another "Core" repository for code you factor out of individual project repos for reuse. As the core becomes more complex, you are then already set up to handle it. Likewise, if you don't write at least some documentation up-front, you're much more likely to never get it done at all.
- asmosoinio 9y agoBased on my experiences, I would disagree. The "core" becomes a mess of versions and dependencies - you still need ALL the other repos to be able to change the code/data there to check all dependencies. Just split with folders within the repo. Anyways this is my opinion, and I know many wise people that disagree with me. And I've seen companies work well with both multiple and single repo. I.e. your mileage may vary.