Git — несколько пользователей используют один и тот же рабочий каталог: проблемы с разрешениями в метафайлах .git

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

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Прежде чем вы меня накажете, я понимаю, что совместное использование рабочего каталога противоречит тому, что означает Git, и я не говорю о выполнении каких-либо операций, кроме операций только для чтения в этом общем каталоге — мы делаем все наши работать в наших собственных локальных репозиториях.

Я открыт для предложений относительно другого способа сделать то, что мы пытаемся сделать, так как наш подход определенно не является лучшей практикой, но я не уверен, что этот разговор будет полезен для других. А пока позвольте мне рассказать кое-что о том, почему мы это делаем:

В нашей команде есть несколько мастеров сборки. Мы развертываем на серверах Linux и делаем там свои сборки с помощью скриптов сборки, которые извлекаются непосредственно из Git. В настоящее время мы не можем использовать CI (например, Jenkins/cruisecontrol), поэтому у нас есть репозиторий, из которого мы проверяем и делаем наши сборки QA.

Некоторые операции git мы выполняем как часть скрипта. Это включает в себя некоторую маркировку коммитов (вещи помечаются как QA-current, QA-previous и т. д.). Так что я думаю, что мы на самом деле не только для чтения полностью. Из-за характера скрипта сборки мы запускаем его sudo'ed как обычный пользователь (назовем этого пользователя DevAdmin). Я понимаю, что это может быть плохой практикой и, возможно, источником боли, поскольку вынуждает нас использовать общую проверку репо.

Все было бы хорошо, если бы мы всегда получали sudo в этом рабочем каталоге. Проблема в том, что иногда один из нас случайно выполнит git pullили что-то подобное, не получив sudo от имени DevAdmin. Так что большинство файлов в .gitпринадлежат DevAdmin (который выполнил первоначальное клонирование), но всякий раз, когда мы это делаем, мы получаем каталоги в .git/objects, которые содержат файлы, принадлежащие конкретному пользователю. И они создаются как групповые, недоступные для записи. Я также заметил, например, ORIG_HEADс неправильным владельцем. Поэтому, когда мы пытаемся что-то сделать от имени DevAdmin, у нас возникают проблемы.

Можем ли мы что-нибудь сделать, чтобы решить эту проблему? Прямо сейчас мы должны признать, что это произошло, а затем заставить администратора сервера chown .gitвернуться к DevAdmin. Или попросите пользователя удалить метафайлы, о которых идет речь, или, по крайней мере, chmodсделать их доступными для групповой записи. Все это кажется очень плохим.

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

Если мы удалим групповой доступ для записи в .gitи ограничим его для DevAdmin, чтобы это не повторилось? Это кажется самым простым вариантом.

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

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

Приветствуются любые мысли.