Проблема. Когда несколько пользователей имеют доступ к одному и тому же рабочему каталогу, в метаданных могут возникать проблемы с разрешениями, если выполняются какие-либо операции git
.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Прежде чем наказывать меня - я понимаю, что совместное использование рабочего каталога противоречит тому, что стоит Git, и я не говорю о том, чтобы делать что-либо кроме операций только для чтения в этом общем каталоге - мы делаем всю нашу работу в наших собственных локальных хранилищах,
Я открыт для предложений относительно другого способа сделать то, что мы пытаемся сделать, поскольку наш подход, конечно же, не самый лучший способ, но я не уверен, что разговор будет полезен для других, чтобы слушать. Поэтому теперь позвольте мне подробно рассказать о том, почему мы это делаем:
У нас есть несколько мастеров по сборке в нашей команде. Мы развертываем серверы Linux, и мы делаем наши сборки там, со сценариями сборки, которые извлекаются напрямую из Git. В настоящее время мы не можем использовать CI (например, Jenkins/cruisecontrol), поэтому у нас есть репозиторий, который мы проверяем и выполняем наши сборки QA.
Есть некоторые операции git, которые мы выполняем как часть скрипта. Это включает в себя некоторые теги коммитов (материал становится помеченным как QA-current, QA-previous и т.д.). Поэтому я думаю, что мы не полностью читаем только целиком. Из-за характера скрипта сборки мы запускаем его sudo
'ed как обычный пользователь (позвольте этому пользователю DevAdmin). Я понимаю, что это может быть плохой практикой и, возможно, является источником боли, поскольку это заставляет нас использовать общий репо-контроль.
Все будет хорошо, если мы всегда будем судиться, когда в этом рабочем месте. Проблема в том, что в некоторых случаях один из нас будет делать git pull
или что-то подобное случайно, не будучи sudo'ed как DevAdmin. Таким образом, большинство файлов в .git
принадлежат DevAdmin (кто выполнил начальный клон), но всякий раз, когда мы это делаем, мы получаем dir в .git/objects
которые содержат файлы, принадлежащие определенному пользователю. И они создаются как неприемлемые группы. Например, я заметил ORIG_HEAD
с неправильным владением. Поэтому, когда мы пытаемся сделать что-то вроде DevAdmin, у нас возникают проблемы.
Есть ли что-то, что мы можем сделать, чтобы исправить эту проблему? Прямо сейчас, мы должны признать, что это произошло, а затем получить администратор сервера, чтобы chown.git
обратно в DevAdmin. Или попросите пользователя удалить метафайлы, о которых идет речь, или, по крайней мере, chmod
их для групповой записи. Все это кажется очень плохим.
Я рассмотрел несколько вариантов, которые не требуют существенного изменения процессов сборки и обслуживания:
Если бы мы удалили доступ к группе для записи в .git
и ограничили его до DevAdmin, это предотвратило бы это повторение? Это кажется наиболее простым вариантом.
Или есть способ сделать все в .gi
t групповой записи, даже когда она была создана? Это похоже на то, чтобы просить о неприятностях.
Есть ли что-то еще очевидное, что мне не хватает? Я понимаю, что лучше всего было бы изменить наш процесс, чтобы пользователи могли работать в своем собственном репо, но в бизнес-настройках репозитории могут быть очень большими (банки еще не выделены, много двоичных файлов и т.д....), и у нас не может быть многопользовательских репозиций для каждой учетной записи. Кроме того, у наших системных администраторов будет много работы, прежде чем они меняют свои процессы, чтобы это сделать.
Любые мысли оцениваются.