Обычный хук пост-получения репозитория git больше не может оформить заказ

Нерожденные (сиротские) ветки

Но есть еще один особый случай: если вы установите HEAD на имя ветки, которая еще не существует (как вы сделали бы, например, с git checkout --orphan), это помещает имя в HEAD без создания ветки. Это достаточно нормально в обычном (не голом) репозитории, за исключением того, что вы видите это только в двух случаях:

• Когда вы впервые создаете новый пустой репозиторий. Вы находитесь на master, но master еще не существует. Вы разрешаете эту ситуацию, помещая коммит в репозиторий, который переходит в master, что создает master. (Новый коммит является корневым коммитом, т. е. не имеет родительского коммита.)

• Когда вы используете git checkout --orphan: это настраивает вас так же, как когда вы находитесь в новом, пустом репозитории, записывая имя ветки в HEAD как обычно, но без создания ветки. Вы разрешаете эту ситуацию, записывая новый коммит, который переходит в нерожденную ветку, которая создает ветку, которая сейчас родилась (существует, указывая на новый корневой коммит, который вы только что сделали).

Делать то же самое в голом репозитории

Очевидно, вы не можете сделать это обычным способом в голом репозитории, потому что обычный способ — работать с рабочим деревом, git add вещей в индекс и git commit. Голый репозиторий не имеет рабочего дерева. (У него все еще есть индекс, и git checkout, что вы можете сделать, когда вы задаете рабочее дерево с --work-tree, по-прежнему записывает сквозь индекс. Это довольно сложно и путается с ловушками развертывания после получения многих людей, поскольку они не понимают индекс.)

То, что вы можете и делаете постоянно, в чистом репозитории — это получение git pushes. Когда вы получаете push, вы принимаете запросы (или команды) от другого Git в форме:

• Пожалуйста, установите вашу ветку master для фиксации 1234567
• Удалить ветку testing

(Вы сами решаете, следует ли и как проверять эти запросы в хуке pre-receive или update. Если вы не делаете ничего особенного, вы получаете встроенные проверки Git по умолчанию, которые позволяют любому создавать или удалять любую ветку или тег, но разрешить ускоренную перемотку вперед только для ветвей.)

Предположим, например, что в вашем голом репозитории есть ветка master, а ветка master еще не существует. Затем кто-то из Interwebs подключается к вашему серверу и говорит: «Эй, ты, голый репозиторий Git, здесь есть несколько коммитов, а теперь создай ветку master, указывающую на коммит 1234567!» В этом случае, предполагая, что вы принимаете этот запрос/команду, как только ваш Git закончит их обслуживание, у вас действительно теперь есть master. Это приведет вас к:

fatal: You are on a branch yet to be born

to:

On branch master

потому что ваша текущая ветвь master, которой раньше не было, теперь существует.

Использование сантехнических команд

команды подключения git update-ref и git symbolic-ref предназначены для использования в скриптах. Они предполагают, что вы точно знаете, что делаете. (Если вы используете их, не зная, что делаете, вы можете создать беспорядок: у них нет встроенных проверок безопасности.) Второй из них, в частности, заключается в том, как Git внутренне устанавливает HEAD, чтобы выбрать, на какой ветке вы находитесь. .

Если вы запустите:

git symbolic-ref HEAD refs/heads/branch

это записывает ref: refs/heads/branch в HEAD, и теперь вы On branch branch. Он не обновляет индекс и не обновляет рабочее дерево, но в голом репозитории нет рабочего дерева, и получение push-уведомления не обновляет index, так что это очень похоже на то, что происходит, когда вы получаете push.

Таким образом, это достаточно безопасное занятие. Это позволяет вам изменить ветку, в которой вы находитесь, без использования git checkout. Это нормальный и правильный, хотя и неудобный — убедитесь, что вы правильно пишете имя ветки и включаете префикс refs/heads/ — способ установить HEAD в голом репозитории.