Сводка
Как наша команда может отключить ветку "доступ на чтение" для отдельных пользователей git? Предлагает ли рынок какие-либо существующие инструменты для автономных сред? Или есть какой-то другой, лучший способ предоставить «отключенный доступ на чтение» для файлов / каталогов git?
До сих пор мы думали, что можем предпочесть контроль доступа на основе git-branch, а) на основе ветвейуправление кажется лучше, чем б) управление на основе каталогов, так как (а) кажется способным сделать все, что может (б) и многое другое.
Мы понимаем, что это сложный заказ для инструмента (git), который разработанскопировать все (в репо) в клон (указанного репо). Мы скептически, но все еще любопытно узнать, существуют ли творческие решения или могут быть изобретены / обнаружены.
Предпочтительные функции
RACL (доступ для чтения -списки управления) для любой ветви, , включая неограниченное количество # отдельных ветвей для любого набора или комбинации пользователей git.
[Необязательно] Интеграция с любое клиентское / серверное программное обеспечение git repo . Таким образом, мы можем теоретически интегрироваться с большинством любых инструментов / экосистем на основе git. Однако, если требуется специальный / пользовательский набор инструментов git, мы рассмотрим его использование.
[Необязательно] Бесшовная интеграция с GitLab . Мы пока не видим, чтобы GitLab предлагал эту функцию. (Мы еще не видим защищенные ветки с функцией «отключить чтение».)
[Необязательно] Git repo с собственным размещением . Мы самостоятельно размещаем сервисы, включая git, для наших важных проектов, когда это возможно. Но пока мы рассмотрим возможность работы с размещенными сервисами, если это единственный способ.
Подробнее
Мы еще не провели эмпирического тестирования ни одной из заявленных функцийот различных поставщиков инструментов для самостоятельного размещения. Но мы провели небольшое исследование . Ничего из того, что мы уже видели, не претендует на функции «конфиденциальности для чтения с отключенным доступом»; Gitolite , возможно, делает?
Кажется, что больше внимания уделяется защите "веток", чтобы избежать сценариев потери данных. Вместо этого, в этом обсуждении меня больше интересует запрет (чтение) доступа назначенных пользователей к конфиденциальной информации.
Можно создать разные git-репо для каждого «группы / класса» доступа, но это проблематично. по многочисленным причинам, включая, но не ограничиваясь:
- , требующим теоретически неограниченного количества репо для каждой комбинации частной информации в масштабах организации.
- неспособность тесно связать частную информациюс информацией о «полной группе», когда требуются отдельные git-репозитории, просто «ограждающие их» друг от друга для обеспечения конфиденциальности внутри группы.
Включение неограниченных «частных» веток git в обычном репо более крупного размеракак более эффективный путь.