-1

I have looked at many related/similar questions, but could not find any sufficient answer to my question.

I have a Gatsby/React project, for which I have one private git repository which is hosted on github. I want to be able to let freelancers work on parts of the project, but I don't want them to be able to see the source code for some parts of the project (at least certain modules and components, perhaps even the main setup of the Gatsby project). They do need to be able to run and test the functionality they create or work on though, which means they need to somehow still get access to the modules/components/config/etc for which I don't want them to see the original code (minified/uglified would be ok).

I know about submodules, but these seem to have a lot of issues which make them unusable for this, mainly:

  1. if I only give a freelancer access to a submodule repository, they can't test integration with the system locally in order to develop with ease and speed. I could probably let them push/merge the submodule into a test branch and have them see the result in a test CI/CD setup. But this means it would take ages to get feedback on every small change.
  2. I have tried out submodules before, and ran into several issues which I couldn't find the solution for easily. Submodules seem to be a bit hard to use, and easy to make mistakes with. Not many developers are experienced with them, and I may end up wasting a lot of time fixing issues with them. I think the use of subtrees instead of submodules can take away a lot of the issues in this point, but it wouldn't help with nr 1, so submodules or subtrees don't seem to be a solution to my problem

Is there some kind of setup I can use to fix my problem and hopefully avoid these issues?

Ruben Lemiengre
  • 104
  • 8

1 Answers1

3

I read that Google, Facebook, etc use one git monorepo for all their code. I can't imagine they would allow their developers to actually pull and see ALL code in their monorepo.

They do. Silos don't scale well, except perhaps at Apple. (Also, Google, Facebook, etc have some great lawyers. Also also, those codebases are big and move quickly and tend to be heavily segmented into discrete microservices. Also also also, what works well at planetary scale probably won't work as well at something smaller.)

If you're intent on keeping certain devs away from certain parts of your codebase, then your only option is to put those secret parts in a separate repository. You don't necessarily have to set up submodules or subtrees - you could define the secret stuff as a library (with binary helpfully provided), or perhaps as a service that the non-privileged devs can query - but there is no way to grant selective read permission in a single Git repository.

Jim Redmond
  • 4,139
  • 1
  • 14
  • 18
  • Thanks Jim for clarifying that. I had to edit out the quoted part though, because some users have deemed it to be opinion-based. – Ruben Lemiengre Aug 08 '23 at 08:09
  • 1
    I would just create separate repos for the subcontractors. When their code is integrated then push to your normal repo. – Rohit Gupta Aug 13 '23 at 05:01
  • @rohit-gupta You mean a copy of the main repo where parts are stripped out? How would I merge the changes into the original repo then? – Ruben Lemiengre Aug 17 '23 at 19:38