2016-05-17 6 views

ответ

3

Этого можно избежать только локальным git pre-commit, поэтому разработчикам необходимо будет создать его. Добавьте файл your-local-project/.git/hooks/pre-commit со следующим содержимым:

#!/bin/sh 

if ! git symbolic-ref HEAD &> /dev/null; then 
    echo "You are in a detached head state! Commit has been blocked. (Use --no-verify to bypass this check.)" 
    exit 1 
fi 

Убедитесь, что это исполняемый файл. Credits go to svachalek

Почему git предотвращает совершение в отдельной головке? Отдельный HEAD означает только, что нет указателя на состояние хранилища, над которым вы работаете. Предполагается, что вы знаете, что делаете.

Я бы предпочел выяснить, почему Многие разработчики в вашей команде входят в это состояние? Может быть, они применяют какой-то странный worklow?

+1

В то время как это предотвратит фиксацию отдельной головы, это также будет мешать (интерактивным) операциям переустановки. Внутри, rebase использует отдельные головы для воспроизведения коммитов. – ad22

+1

Разрешение на пересылку потребует [обнаружения их] (http://stackoverflow.com/questions/3921409/how-to-know-if-there-is-a-git-rebase-in-progress) в hook. Тем не менее, я с трудом могу представить разработчика, который делает интерактивную перезагрузку, и боится совершать в отдельном ГОЛОВке одновременно. – fracz

1

git checkout $commit-sha1 может привести к отсоединенной головной части. Точно так же git checkout FETCH_HEAD. Отдельную головку можно рассматривать как ветку без названия. Если это вас не смущает, вы можете просто игнорировать его. Как сказал @fracz, вы можете предотвратить его на pre-commit. Вы также можете сделать его веткой с именем с git checkout -b some_name. Крючок post-checkout может помочь вам определить состояние отсоединенного состояния HEAD и сделать его ветвью.

+0

+1 для идеи создания ветки в крючке 'post-checkout'. Тем не менее, это должно было бы создать ветви со случайными именами, которые, в свою очередь, создавали бы большой беспорядок во времени. – fracz

+0

@fracz Да, случайное название ветви действительно является проблемой. Мы могли бы использовать некоторую логику, чтобы найти собственное имя, но, напротив, это все еще немного хлопотно. Поэтому просто игнорируйте его или найдите основную причину и предоставьте ее заранее. Как я знаю, 'repo sync' без' repo start' также может привести к отключенному состоянию HEAD, если используется Repo. – ElpieKay

+0

Создание ветки в кучке 'post-commit' позволит избежать создания ветвей, когда пользователь фактически не хочет ничего совершать. См. Https://gist.github.com/ben-cohen/316f89c763e9d8a027335261a44c4954 –

0

Git использует это внутренне для многих операций. Отключенный режим HEAD просто приводит вас к одной (одной, отдельной, специальной) анонимной ветке, а анонимной ветке может быть присвоено имя позже.

Это, например, как git rebase удается скопировать коммиты из своей первоначальной цепочки в новую цепочку. Сначала он проверяет целевое совершение --onto (--onto по умолчанию <upstream>), используя этот автономный режим HEAD. Затем для каждой фиксации, которая должна быть скопирована, она копирует эту фиксацию (с git cherry-pick или с чем-то эквивалентным: детали зависят от интерактивной и неинтерактивной переадресации, а в случае интерактивности - более подробной информации). Наконец, он перемещает существующую метку ветки, чтобы она указывала на окончательную скопированную фиксацию.

 Смежные вопросы

  • Нет связанных вопросов^_^