obfuscation - GIT - Maintaining obfuscated repositories for working with untrusted 3rd party developers? -

our git repositories typically contain code our entire websites & services. includes painstakingly worded text marketing, legal, ui, etc.

essentially rogue developer clone it, change few things, , become competitor of ours (all legal issues aside). or more likely, include others work own in portfolios without authorization. in cases leads disclosure of features , functions don't want out there yet.

in case, has been recognized risk since work developers around globe , have need add more -- granting them access entire code base work on.

have ever encountered issue? or have implemented solution reduce or mitigate similar risks?

i thinking 1 potential strategy create 3 individual git repositories different purposes (not branches) this:

git repo: project1_developers

$git branch master dev issue_feature1 issue_feature2 etc.. 

workflow above: issue/feature branch style. developer delegated task, checks out issue/feature branch. when completed, submits branch & merge request dev branch. test branch & merge dev if ok.

above how things today. that's it. whole repo there in 'master' gets published world.

but meet stated goal i'm thinking add like...

git repo: project1_obfuscate

$git branch strips_and_swaps (for sending developers repo) prod_patches (the patches make "whole" again) prod_master (branch production repo pulls master branch?) 

and production repo...

git repo: project1_production

$git branch master 

as far content problem goes, imagine simple webpage repo...

.git index.html logo.png 

so goal strip out or patch in real/fake "logo.png" dummy logo branches in "developers" repo.

in practice, instead of logo.png, maybe bunch of .blade files (laravel) .twig files or whatever template files might have content bits wish restrict access to. in cases, maybe files exist in teh "obfuscate" remote.

has done similar might share insight?

it hurts head think doing way i'm suggesting, , might not work :)

the best practice is, if possible, isolate sensitive information in own git repo instead of keeping in 1 giant repo.

you still can have global picture using parent repo reference other repos submodules.

but if sensitive data in 1 repo, can protect in term of access.
easier trying protect branch (you can protect against push, not pull, meaning 1 can still have access content) or obfuscate remote url.