2012-05-31 3 views
4

Я пытаюсь использовать git таким образом, чтобы некоторые подкаталоги в проекте скрывались/скрывались от «ненадежных» пользователей, но были видны другим «доверенным» пользователям. Обратите внимание, что это не только защита от записи; ненадежным пользователям также не разрешается читать секретные файлы. Я бы хотел, чтобы пользователь выглядел так, как если бы это был единственный git-репо, а не что-то вроде подмодулей.скрывает часть git repo от ненадежных пользователей

Я расскажу вам свою единственную идею до сих пор, в случае, если это вызвало некоторую дискуссию или критику. Я рассматриваю возможность наличия двух параллельных репозиториев за кулисами на сервере. Доверенные пользователи клонируют/тянут/нажимают доверенное репо. Неверные пользователи клонируют/тянут/нажимают ненадежное репо. Когда выполняется фиксация доверенного репо, он фильтруется для удаления секретного содержимого перед его применением к ненадежному репо. Переход в другое направление, фиксация ненадежного репо фильтруется, чтобы избежать сглаживания секретного содержимого перед тем, как его применить к доверенному репо.

Как я должен достичь этой цели? Является ли мое предлагаемое решение безумным?

+1

Я пошел с ответом «hack git yourself», так как это единственный, который даст простой пользовательский опыт, который я хотел. Это было непросто, и мне пришлось нанять опытного вкладчика в проект git, чтобы это произошло. Большая картинка, он сделал это с git-крючками и отдельным репозиторием для каждого набора разрешений. По крайней мере, это не требовало изменения исходного кода git. После нескольких месяцев использования он работает, и он прост для пользователей. Я волнуюсь, это может быть немного хрупким и жить в постоянном страхе перед моим следующим толчком, обращая его в недоумение. Я не могу сказать, что рекомендую этот маршрут другим, но он делает то, что я хочу. – RaveTheTadpole

ответ

1

Возможно, это технически возможно, если вы планируете взломать git. Несколько вопросов, на которые вам нужно ответить:

  • Как вы будете идентифицировать «секретные» файлы во время нажатия на сервер?
  • Как вы убедитесь, что вы подключаете к ваш сервер? Поскольку никакой другой сервер не будет фильтроваться должным образом, нажатие на неправильный сервер будет передавать все секретное содержимое.

Если вы взломали git, все возможно.

+0

«Секретные» файлы могут быть идентифицированы, поскольку они находятся в каталоге, который идентифицирован (в некотором конфигурационном файле) как секретный. Или что-то типа того. Что касается обеспечения моего сервера, я думаю, мне просто нужно доверять доверенным пользователям, чтобы они не толкали его туда, где они не должны. – RaveTheTadpole

1

Невозможно ограничить доступ к частям репо.

Имея секретный контент в другом репо, и этот репо как подмодуль для основного является самым простым способом. Сохранение синхронности двух репозиций, которые отфильтрованы, на самом деле невозможно.

+0

OP уже сказал, что он явно не хочет, чтобы субмодульный опыт. –

3

Да, это возможно и регулярный спрос.

Для этого вы должны разделить свое репо на несколько разных репозиториев и использовать git submodule, чтобы объединить тему с одним репо. Затем вы закрываете разрешение секретного репо на недоверенного пользователя.

Например, моя домашняя конфигурация является публичным репо в github: https://github.com/perfectworks/home. Вы можете найти каталог private, который является подмодулем для другого частного git-репо. Неверные пользователи не могут получить что-либо в этом каталоге, если я не разрешу им право.

Подробнее о git submodule можно найти здесь: http://git-scm.com/book/ch6-6.html.

1

Поскольку вы говорите, что не хотите использовать подмодули, вы можете взглянуть на git-subtree, что позволяет отделить подкаталог репозитория в своем собственном репозитории и слить обратно изменения, которые были совершены просто к этому другому репозиторию. Затем можно использовать следующую структуру:

full-repo 
\ 
.git 
public 
private 

... и использовать git-subtree split генерировать ветвь, которая просто представляет историю подкаталоге public, и принести эту ветвь в недавно созданном хранилище.Затем вы позволяете привилегированным пользователям клонировать full-repo, а ненадежные пользователи могут только клонировать новый репозиторий, который представляет подкаталог public. Когда изменения привязаны к репозиторию, представляющему подкаталог public, вы можете объединить эту историю в full-repo, взяв исходный репозиторий и запустив git-subtree merge. Аналогичным образом, изменения, сделанные в full-repo, могут иметь часть, которая влияет на public, распространяемую на разветвленную ветвь с git subtree split и вытягивая эту ветвь в разделенный репозиторий.

Обратите внимание, что если вы хотите это сделать, при распространении изменений обратно в репозиторий, представляющий public, вам нужно быть очень осторожным, чтобы вы не собирали объекты, которые являются частными в публичном репозитории. Например, убедитесь, что вы просто извлекаете разделенную ветку, а не все в репозитории. Я бы не использовал этот подход в ситуации, когда безопасность была критической, на случай, если бы одна совершила ошибку такого рода.

Смежные вопросы