Вопрос: Как я могу совместно использовать репозиторий Git с несколькими пользователями на компьютере?


У меня есть репозиторий Git на промежуточном сервере, на который должны быть способны несколько разработчиков. git-init похоже, имеет флаг, очень близкий к тому, что я ищу: --shared, за исключением того, что я хотел бы, чтобы несколько человек вытащили этот репозиторий. git-clone«s --shared флаг делает что-то совершенно другое.

Какой самый простой способ изменить существующие разрешения репозитория?


196
2018-06-17 01:04


Источник


Я использую «Github для Windows» и переключаюсь между двумя учетными записями Github: stackoverflow.com/questions/18565876/... - Alisa


Ответы:


Разрешения - вредитель.

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

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

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

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

chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo

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

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

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

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

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

setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX

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

Надеюсь, что ты пойдешь.


170
2018-06-17 06:00



git init имеет параметр под названием --shared, который устанавливает переменную core.sharedRepository для групповой работы. Вы также можете установить переменную в существующем репозитории. Это устраняет необходимость ручной установки umask, так как git будет устанавливать значение разумного значения перед манипуляцией файлами. - ptman
+1 для расширенных атрибутов POSIX - новости для меня! - RobM
Когда я сделал chmod -R g+swX, это сделало Git очень недовольным, и он решил, что это больше не репозиторий git («репо не похоже на репозиторий git»). Я должен был chmod g-s все файлы, Чтобы просто установить бит setgid на каталоги, пытаться find /path/to/repo -type d -print0 | xargs -0 chmod g+s, Еще chgrp -R thegroup /path/to/repo, - rescdsk
chmod -R g+swX gitrepo будет применять бит setguid к файлам, что представляет угрозу безопасности. Вместо этого вы можете использовать find . -type d -exec chmod g+s {} + применять его только к каталогам. - Ian Dunn
ACL (setfacl) не имеет установки для setgid для принудительного применения новых файлов и подкаталогов, созданных в каталоге, чтобы наследовать его идентификатор группы. Поэтому вы должны установить setgid отдельно через chmod. Опция Git --shared (git-scm.com/docs/git-init), однако, позволяет вам устанавливать и переопределять umask пользователя. - Chase T.


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

$ git init --shared=group 

или

$ git init --shared=0NNN

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

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


113
2018-02-17 05:40



Это, безусловно, правильный ответ. - ELLIOTTCABLE
У меня была эта проблема, и это, безусловно, лучший ответ. Единственная проблема заключается в том, что --shared аргумент принимает восьмеричный, а не шестнадцатеричный. Я подтвердил это в источнике Git 1.7.8, а второй пример должен быть git init --shared=0NNN, - qpingu
Что NNN- маска промахов, номер группы или что-то еще? - Craig McQueen
BTW, «group» выше - это ключевое слово, а не местозаполнитель для вашего имени группы. Вы назначаете группу с помощью команды chgrp. Для нового репо это git init --bare --shared=group myproj где myproj - ваше имя вашего репо, а затем chgrp -R mygroup myproj где mygroup - ваше имя группы. - labradort
Подсказывает, что если ваши пользователи совершают фиксации, когда их группа по умолчанию отличается от того, что она должна быть, она может повредить вещи. Чтобы устранить эту проблему, вам понадобится каждый пользователь, чтобы chgrp каждый файл, который им принадлежит в репо, в нужную группу. Это будет повторяться, если вы не выясните, как заставить всех создавать / переключать новые файлы под / в нужную группу до совершения и нажатия. - ragerdl


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

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

[core]
    sharedRepository = true

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


50
2018-03-09 05:52



Согласно git-config (1) (kernel.org/pub/software/scm/git/docs/git-config.html) core.sharedRepository, вам нужно установить это на «umask» или «false», чтобы git уважал umask пользователя. - David Schmitt
Это и ответ user35117 верны. Обратите внимание, что «true» совпадает с «group», и это можно установить с помощью команды git config core.sharedRepository true, - ColinM
По-прежнему ли он изменяет права собственности на файл, когда он перенаправляется на удаленный? - Silentbang
Если вы хотите установить это при клонировании, а не после факта, эквивалент git init --sharedявляется git clone --config core.sharedRepository=true, Странный git для использования --shared для таких разных значений в таких похожих командах. - stevek_mcc


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

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

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


20
2018-06-17 07:35



Мне нравится Гитозис. Это довольно эффективный способ контроля доступа на основе открытых ключей. - Mike Mazur
Как любой из этих решений решает проблему «Я бы хотел, чтобы несколько человек вытащили этот репозиторий»? - womble♦
взгляните на гитоз. что один решает вашу проблему. - pilif
Когда вы делите репозиторий, люди смогут извлечь из него. Скорее всего, им придется клонировать его или добавить удаленную ветку. Документация, которую я связал, очень четко проведет вас через решение вашей проблемы; Я использовал все описанные методы, чтобы помочь разработчикам совместно использовать исходный код с Git. Насколько мне известно, ServerFault не предназначен для удержания рук. - jtimberman
Я должен согласиться с использованием Гитоза. Он обходит проблему с разрешениями, используя одну учетную запись, аутентифицированную несколькими SSH-ключами. Он также полностью управляется посредством git-коммитов. - Jeremy Bouse


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


9
2018-01-19 08:55





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

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

/myrepo.git/hooks/post-update

#!/bin/sh
chmod -R g+w . 2>/dev/null
chgrp -R mysharedgroup . 2>/dev/null

4
2017-09-27 14:35



правильный ответ, когда пользователи имеют разные группы по умолчанию - Pat
Установка бита setgid в каталоге приведет к тому, что файлы, созданные пользователями, наследуют одно и то же групповое владение как каталог (если пользователи принадлежат к этой группе). Даже если это не группа пользователей по умолчанию. Тогда этот крючок не нужен. Это то, что делает ответ @ womble (и мой комментарий к нему). - rescdsk
На моем компьютере centos7 после попытки каждого решения, перечисленного на этой странице, вариант решения @ bkmks выше был единственным вариантом, который фактически работал (установка переходов после слияния и пост-проверки вместо пост-обновления, как указано выше). - Mike Godin


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

РЕДАКТИРОВАТЬ:

Также проверьте эту статью 8 способов поделиться своим хранилищем git,


2
2018-06-17 02:58





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

Если вы создаете новый репо 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: deny non fast-forward подталкивает к репо

Если вы хотите точно настроить права пользователя, группы или других пользователей, используйте --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(чтобы убедиться, что репо инициализировано с правильным владельцем для всех исходных файлов и подкаталогов).


2
2018-05-26 01:24





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

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

chgrp -R <whatever group> gitrepo
chmod -R g+wX gitrepo
cd gitrepo
find . -type d -exec chmod g+s {} +
git config core.sharedRepository group

1
2017-12-13 12:44