Git меняет права доступа к файлу при оформлении заказа

Наш рабочий процесс разрабатывается на локальной машине, фиксирует изменения в центральном репозитории, а затем проверяет ветвь этого репозитория, который нам нужен.

Проблема заключается в том, что Git изменяет права собственности и даже права доступа к файлам, которые он проверяет, в зависимости от пользователя, делающего проверку. Прямым результатом этого является то, что наши CSS файлы становятся нечитабельными после проверки, так как Git изменяет владельца файла на человека, который выполнил Git pull в webroot.

Пример:

  • До git pull: style.css принадлежит user_a:group_a
  • После git pull: style.css, принадлежащего user_b:user_b

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

Как другие люди справляются с этим? Как вы работаете с репозиториями, используемыми несколькими пользователями. У нас есть suphp в нашей системе и мы не можем его снять.

Ответы

Ответ 1

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

Git поддерживает два набора разрешений: исполняемый бит и исполняемый бит. Ничего больше. Информация о владельце не сохраняется вообще.

См. этот поток - "Если вам нужны определенные разрешения, вам нужно сделать это вручную".

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

Как и @ikke в комментариях, git на самом деле не является инструментом развертывания и не должен использоваться как таковой. Это система управления версиями исходного кода.

Ответ 2

Для меня лучшим решением было создание оболочки script, которая исправляет разрешения. Например:

.git/hooks/post-checkout:

#!/bin/sh
chmod +x  tools/*

Btw, проверка не является единственным случаем, когда git работает с разрешениями, а также при нажатии. Я обрабатываю это с помощью .git/hooks/post-merge hook.

В идеале вы можете создать оболочку script, которая исправляет разрешения где-то в вашем репо (например, tools/fixpermissions.sh) и вызывает его в обоих случаях. Не забудьте изменить разрешения для этого файла вручную;)

#!/bin/sh
chmod a+x tools/fixpermissions.sh
tools/fixpermissions.sh

Ответ 3

Самое простое решение - просто запустить git как user_a.

Ответ 5

Я часто запускаю

git checkout -f file.xml

... на версии file.xml с разрешениями на запись в мире, так как я постоянно изменяю его и хочу вернуть его в нормальное состояние.

Но это сбрасывает разрешения. Немного более длинная версия:

git show HEAD:./file.xml > ./file.xml

Просто сбрасывает содержимое.