Разрешения являются вредителями.

В принципе, вам нужно убедиться, что все эти разработчики могут писать все в репозитории git.

Перейдите к New-Wave Solution для превосходного метода предоставления возможности записи групп разработчиков.

Стандартное решение

Если вы разместите всех разработчиков в специально созданной группе, вы можете в принципе просто:

chgrp -R <любая группа> gitrepo
chmod -R g + swX gitrepo

Затем измените umask для пользователей на 002, чтобы новые файлы создавались с разрешениями для групповой записи.

Проблемы с этим - легион; если вы используете дистрибутив, который предполагает umask of 022 (например, с общей группой users, которая включает всех по умолчанию) это может открыть проблемы безопасности в других местах. И рано или поздно что-то испортит вашу тщательно продуманную схему разрешений, поставив репо из строя до тех пор, пока вы не получите доступ к root и не исправите ее (т. Е. Повторите приведенные выше команды).

Новое волновое решение

Отличное решение - хотя и менее понятное, и для которого требуется немного больше поддержки ОС /инструмента - использовать расширенные атрибуты POSIX. Я только недавно пришел в эту область, поэтому мои знания здесь не такие горячие, как это могло бы быть. Но в основном расширенный ACL - это возможность устанавливать разрешения только на 3 слота по умолчанию (пользователь /группа /другой).

Итак, еще раз создайте свою группу, а затем запустите:

setfacl -R -m g: <любая группа>: rwX gitrepo
найти gitrepo -type d | xargs setfacl -R -m d: g: <любая группа>: rwX

Это устанавливает расширенный ACL для группы, чтобы члены группы могли читать /записывать /получать доступ к тем файлам, которые уже есть (первая строка); затем также сообщите всем существующим каталогам, что новые файлы должны иметь тот же самый ACL, который применяется (вторая строка).

Надеюсь, что ты по пути.

, если вы создали репозиторий (или клонировали новое голое репо с существующего) с помощью

$ git init --shared = group

или

$ git init --shared = 0NNN

Предполагается, что Git обрабатывает разрешения выше и выше того, что предоставляет ваш umask по умолчанию. Наконец, это верно в моей версии Git (1.6.3). Конечно, это предполагает, что ваши пользователи находятся в одной группе.

Если бы мне нужно было управлять пользователями в нескольких группах с различной степенью чтения /записи, я бы пошел с гитозом. Я также слышал упоминание о гитолите ( http://github.com/sitaramc/gitolite ), викторине гитозиса, которая предположительно предоставить разрешения на уровне филиала, не могу сказать, что я использовал его лично, хотя.

Это не сказано, поэтому я хочу быстро добавить его.

Чтобы гарантировать, что проблемы с разрешениями не обрезают свою уродливую голову, обязательно установите следующие параметры в файле конфигурации git shared repository:

[ядро]
    sharedRepository = true

Это гарантирует, что настройки вашей системы «umask» соблюдаются.

Руководство пользователя Git описывает, как поделиться репозиторием в несколькими способами.

• Экспорт через Git Daemon .
• Экспорт через HTTP .
• Стиль CVS /SVN, один общий репозиторий , где разработчики push /pull.

Более сложные, хотя полнофункциональные способы обмена репозиториями:

• Гитоз
• GitHub (или GitHub Установка брандмауэра )

Мы используем GitHub для команды из 6 разработчиков.

Также посмотрите gitolite для размещения своего репозитория git. Гитоз, по-видимому, больше не развивается.

Один из способов исправления разрешений в общем репозитории, поэтому пользователи не будут иметь проблем с разрешением при нажатии, заключается в создании сценария крюка после обновления, который будет делать именно это. Это должно работать в любой версии git.

Предположим, что у вас есть общий репозиторий в /myrepo.git. Все файлы в этом репозитории принадлежат mysharedgroup . Все пользователи, нажавшие на этот репозиторий, должны также принадлежать mysharedgroup . Теперь создайте следующий файл (изменив mysharedgroup на ваши настройки):

/myrepo.git/hooks/post-update

#! /Bin /ш
chmod -R g + w. 2 > /DEV /нуль
chgrp -R mysharedgroup. 2 > /DEV /нуль

Вы можете использовать git-daemon для совместного использования репозитория. Прочтите документацию для git-daemon для больше информации.

EDIT:

Также проверьте эту статью 8 способов поделиться своим репозиторием git .

Чтобы собрать кусочки полезных советов из различных других ответов и комментариев о настройке нового репо:

Если вы создаете новый репо myrepo в /srv /git для группы mygroup, это то, что вы хотите

mkdir /srv/git/myrepo.git
chgrp mygroup /srv/git/myrepo.git
git init --bare --shared /srv/git/myrepo.git

1. первая строка создает репо dir
2. вторая строка устанавливает свою группу в mygroup
3. третья строка инициализирует голый репо со следующей конфигурацией:
   1. core.bare = true: сделать это голым репо
   2. core.sharedrepository = 1 (то же, что и core.sharedrepository = group): каталог repo и все созданные позже в нем каталоги будут управляться git, чтобы разрешить mygroup для чтения, записи и выполнения (с установленным битом sgid - для работы с пользователями, для которых mygroup не является их основной группой)
   3. receive.denyNonFastforwards = 1: запретить немедленную переадресацию на репо

Если вы хотите точно настроить права пользователя, группы или других пользователей, используйте - shared = 0NNN, где NNN являются стандартным пользователем, группой , и другие биты для файлов (бит execute и sgid в каталогах будет управляться соответствующим образом git). Например, это позволяет читать и записывать доступ к пользователю и доступ только для чтения к группе (и не имеет доступа к другому):

git init --bare --shared = 0640 /srv/git/myrepo.git

Это позволяет читать и записывать доступ к пользователю и группе (и не имеет доступа к другому):

git init --bare --shared = 0660 /srv/git/myrepo.git

Это позволяет читать и записывать доступ к пользователю и группе и доступ только для чтения к другому:

git init --bare --shared = 0664 /srv/git/myrepo.git

Обратите внимание, что если вы не собираетесь разрешать доступ к записи для группы, сначала используйте chown, чтобы установить владельца репо, а затем запустите git init в качестве этого пользователя (чтобы убедиться, что репо инициализировано с правильным владельцем для всех исходных файлов и подкаталогов).

Выполнение именно этого сработало для меня, для существующего репозитория. Это дает советы от нескольких ответов и комментариев до:

Из родительского каталога репозитория на сервере:

chgrp -R <любая группа> gitrepo
chmod -R g + wX gitrepo
cd gitrepo
найти . -тип d -exec chmod g + s {} +
Группа git config core.sharedRepository

@stevek_mcc ответ - это тот, который я искал, когда искал этот вопрос по этому вопросу

git clone --config core.sharedRepository = true