GIT - Поддерживать запутанные репозитории для работы с ненадежными сторонними разработчиками?

Question

Наши репозитории git обычно содержат код для всех наших сайтов и сервисов. Это включает в себя весь кропотливо сформулированный текст для маркетинга, юриспруденции, пользовательского интерфейса и т. Д.

По сути, мошеннический разработчик может клонировать его, изменить несколько вещей и стать нашим конкурентом (все правовые вопросы в стороне). Или, что более вероятно, они часто включают в свои портфели другие работы без разрешения. В некоторых случаях это приводит к раннему раскрытию функций и функций, которые нам пока не нужны.

В любом случае, это было признано риском, поскольку мы время от времени работаем с разработчиками по всему миру, и нам нужно добавлять их в ближайшее время - предоставляя им доступ ко всей кодовой базе, над которой они будут работать.

Вы когда-нибудь сталкивались с этой проблемой? Или внедрили решение для уменьшения или смягчения аналогичных рисков?

Я думаю, что одной потенциальной стратегией может быть создание 3-х отдельных git-репозиториев с разными целями (не ветвями), но что-то вроде этого:

Git Repo: Project1_DEVELOPERS

$git branch
master
dev
issue_feature1
issue_feature2
etc..

Рабочий процесс выше: в основном стиль выпуска / функции ветки. Разработчику поручается задача, которая проверяется как ветвь проблем / функций. По завершении отправляет запрос на ветку и слияние в ветку dev. Мы проверяем ветку и сливаемся с dev, если все в порядке.

Выше в основном, как мы делаем вещи сегодня. Вот и все. Весь репо находится в "мастер", как он публикуется в мире.

Но для достижения поставленной цели я думаю ДОБАВИТЬ что-то вроде...

Git Repo: Project1_OBFUSCATE

$git branch
strips_and_swaps (for sending to DEVELOPERS repo)
prod_patches (the patches to make it "whole" again)
prod_master (branch that PRODUCTION repo pulls into its master branch?)

и производственный репо...

Git Repo: Project1_PRODUCTION

$git branch
master

Что касается содержания проблемы, представьте простую веб-страницу в качестве репозитория...

.git
index.html
logo.png

Так что моей целью было бы раздеть или залатать настоящий / фальшивый "logo.png" с фиктивным логотипом из веток, которые есть в репо "DEVELOPERS".

На практике вместо logo.png, возможно, это будет набор файлов.blade (Laravel) .twig или любые другие файлы шаблонов, которые могут иметь биты содержимого, доступ к которым мы хотим ограничить. В некоторых случаях, возможно, файлы существуют ТОЛЬКО в пульте "OBFUSCATE".

Кто-нибудь сделал что-нибудь подобное этому, кто мог бы поделиться некоторым пониманием?

Мне больно думать, что я поступаю так, как я предлагаю, и это может даже не сработать:)

Answer 1

Лучшая практика - по возможности изолировать конфиденциальную информацию в собственном репозитории Git, а не хранить все в одном гигантском репо.

Вы по-прежнему можете иметь общую картину, используя родительское репо, которое будет ссылаться на все остальные репо как подмодули.

Но если конфиденциальные данные находятся в одном репо, вы можете защитить их с точки зрения доступа.
Это проще, чем пытаться защитить ветку (вы можете защитить от push, а не pull, то есть можно иметь доступ к ее содержимому) или скрыть удаленный URL.