Gitolite или Gitosis: разрешение на каталог внутри хранилища - PullRequest
Новая
       10

Gitolite или Gitosis: разрешение на каталог внутри хранилища

3 голосов
/ 08 ноября 2011

Например: у меня есть репозиторий - repo1 с такой иерархией fs 

repo1:
 js
 html
 php/core
 php/menu

И я хочу дать repo1:php/menu разрешение RW - фрилансеру, но для всех репо1 - этот фрилансер должен иметь только разрешение только для чтения.

Могу ли я сделать это с помощью гитолита или гитоза или что-то еще?

Ответы [ 3 ]

6 голосов
/ 08 ноября 2011

Права доступа к репо в DVCS всегда связаны со всем репо, а не частью if, главным образом потому, что вы клонируете все его ( мелкий клон - жесткий ).

Это означает, что gitolite (я даже не буду упоминать устаревший gitosis) может устанавливать ограничения на:

  • доступ ко всему репо
  • написание только определенных веток (но вы не можете ограничить доступ для чтения к определенной ветке)

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

Однако, начиная с gitolite v3 или 'g3' (17 апреля 2012 г.), вы можете, с помощью правил VREF , предотвратить запись (нажатие на) определенные каталоги (в дополнение к определенным ветвям).

Оригинальный ответ ( gitolite V2 или 'g2' , ноябрь 2011 г.)

См. gitolite.conf - в качестве примера и примечание: разрешения "R" для ссылок 

repo    gitolite-admin
        RW+                 =   sitaram
        # this is equivalent to:
        RW+     refs/.*     =   sitaram

Ситарам - единственный админ. Он может вставлять, создавать, удалять или перематывать любые ветки или теги в репозитории gitolite-admin. 

        R master    =   wally       # MEANINGLESS!  WILL NOT DO WHAT YOU THINK IT DOES!

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

0 голосов
/ 08 ноября 2011

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

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

То, что вы можете ограничить, - это "толчок" в центральное хранилище. Вы можете создать хук update или pre-receive (они отличаются только соглашением о вызовах), который будет проверять содержимое ревизий и отклонять их, если они касаются чего-то, что вам не нужно. Хук update получает 3 аргумента: имя ветки, старый коммит и новый коммит, так что вы просто git diff --name-status старый и новый коммит и, если задан пользователь (вам придется посмотреть, как получить это из gitolite), выполнение push и изменения влияют не на тот подкаталог, который вы разрешаете, отклоните push.

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

Обратите внимание, что проверка авторов коммитов или коммиттеров небезопасна, поскольку автора можно установить свободно.

0 голосов
/ 08 ноября 2011

То, что вы хотите сделать, кажется возможным с гитолитом.Посмотрите на это: http://sitaramc.github.com/gitolite/bac.html

Доступ на чтение будет только на уровне репо, но в любом случае это то, что вы хотите ..

...