Git clone предотвращает клонирование репозитория рабочей копии (не голого)
Если вы сделаете клон рабочей копии git (репозиторий с рабочим деревом), измените некоторые файлы, выполните фиксацию и попытайтесь нажать, вы получите сообщение:
remote: error: refusing to update checked out branch: refs/heads/master
...
! [remote rejected] master -> master (branch is currently checked out)
Для меня это понятное и желанное поведение.
Я хотел бы предотвратить случайное клонирование рабочей копии репозитория.
Как запретить git clone клонировать рабочие копии вместо удаленных голых репозиториев и сигнализировать об ошибке в случае попытки клонировать рабочую копию?
Есть ли какой-либо переключатель командной строки, который вызывает git clone ненулевой статус выхода в случае попытки клонировать рабочую копию вместо чистого удаленного репозитория?
Если нет, то как проверить местоположение репозитория (URL-адрес или путь к каталогу), если он содержит пустой репозиторий, чтобы я мог проверить это в bash перед клонированием.
Обратите внимание, что рабочая копия репозитория не обязательно означает, что она локальная, потому что она также может использоваться удаленно.
В моем случае git clone должно быть разрешено работать только с голыми репозиториями git и сигнализировать об ошибке, если используется для клонирования рабочей копии.
2 ответа
Невозможно предотвратить клонирование репозитория с рабочим деревом. Когда Git фиксирует содержимое в репозитории, они становятся доступными при доступе к.git каталог или его эквивалент без какой-либо проверки или изменения рабочего дерева.
Это на самом деле чрезвычайно важно для безопасности, потому что одна из единственных безопасных вещей, которые вы можете сделать с ненадежным репозиторием, - это клонировать или извлекать из него. Если бы вам не позволили сделать это, не было бы возможности получить данные из ненадежных репозиториев безопасным способом.
Вы можете проверить, есть ли в локальном репозитории рабочее дерево, запустив git rev-parse --is-bare-repository в рассматриваемом репозитории (или используя -C). Он напечатаетtrue если он голый (то есть не имеет рабочего дерева) и falseесли это не так. Вы не можете проверить это в репозитории, который недоступен через локальную файловую систему (например, удаленный HTTPS или SSH), потому что это потребует от вас возможности проверить файловую систему удаленной системы, и это будет проблемой безопасности, если удаленные пользователи могут сделай это.
Я рекомендую не слишком беспокоиться об этом сценарии вместо того, чтобы пытаться бороться с Git по этому поводу. Такое поведение создает несколько практических проблем и обычно не должно вызывать беспокойства.
Чтобы дополнить ответ bk2204, вы должны думать о рабочем дереве как о не части репозитория... потому что в довольно сильном смысле оно не является частью репозитория. Поскольку дерево работ не является частью репозитория, оно никогда не копируетсяgit clone. Значит, здесь нет никаких проблем.
(Индекс Git и файлы, скопированные в индекс, являются, по крайней мере, своего рода частью репозитория, но сам индекс не копируется. Объекты BLOB-объектов - содержимое файлов - которые были вновь сохранены в репозитории Git через git add, но которые еще не были зафиксированы, потенциально могут быть скопированы, хотя в целом объекты, на которые нет ссылок, не должны копироваться во время клонирования. Я почти уверен, что хотя бы раз встречал экземпляры объектов, на которые нет ссылок, в свежем клоне, еще в дни Git 1.5.5 / Git 1.6. Но рабочие файлы деревьев, которые никогда не былиgit add-ed вообще не имеют представления в базах данных репозитория, и именно они копируются во время клонирования.)