Мы компания по веб-разработке, которая переходит на Git.
В конечном итоге мы намерены запустить его полностью локально, но в настоящее время у нас есть веб-сайты разработки, размещенные на сервере Linux, где также находятся репозитории Git (которые я создаю через Tower на моем собственном компьютере).
Наши разработчики подключаются к этому серверу через AFP (Mac) или Samba (Windows / Linux) и используют комбинацию Tower и Sourcetree для регистрации этих изменений.
Наша папка веб-разработки на этом сервере является общей и разрешенной, поэтому все операции чтения / записи выполняются от имени пользователя www-data. Ни в коем случае не идеальный вариант и не то, чем я бы занимался в производстве, но это работает для нас. В основном....
Время от времени при попытке обработать измененные файлы или зафиксировать их появляется это сообщение об ошибке:
fatal: unable to write new_index file
Иногда это просто «индекс» без префикса «new_».
Я обнаружил, что подключение по SSH к серверу в качестве пользователя www-data, переход к папке .git в проекте, а затем переименование индекса во что-то другое и обратно часто решает эту проблему. Разрешения (660) верны для файла до и после этого, но трюк с переименованием, похоже, работает.
Помимо очевидной долгосрочной цели по запуску Git / веб-сайтов на собственных машинах разработчика, есть ли решение для этого - или просто не рекомендуется удаленное управление репозиторием Git?
Похоже, вы действительно разделяете то же самое работает репо для нескольких пользователей, что в целом не очень хорошая идея:
Я бы предложил создать групповой голый репозиторий git (специально разработан для обмен) на том же самом разделе, доступном для машин разработчиков так же, как и в текущем репо (там много информации, вы можете начать с https://stackoverflow.com/questions/7632454/how-do-you-use-git-bare-init-repository):
git clone/git pull из этого голого репо в свои местные работает репо, где они делают git commit их изменения, а затем git push их обратно в общее репоgit pull в этом случае можно будет «обновить» контент со всеми коммитами, вставленными в голое репо с момента последнего git pull (после этого может потребоваться перезапуск httpd)