Спасибо за указатели на запись FAQ о переходе на ветку в / refs / remotes / вместо master - это интересный вариант! Варианты использования, которые меня здесь больше всего интересуют, однако, это случаи, когда: 1. непосредственно в репо не выполняется никакой работы (т. Е. Рабочий каталог никогда не будет загрязнен) 2. репо необходимо перенести на 3 репо также должен быть в состоянии делать вытягивания / слияния. Я привел несколько примеров в своем ответе Карлу выше (отдельные центральные стабильные / нестабильные репозитории, «промежуточные» репозитории, используемые для интеграционного тестирования) - я был бы также признателен за ваши мысли об этих случаях! :)

бы воспользоваться некоторыми рекомендациями экспертов по git относительно того, как сделать операции push в безопасных репозиториях. В основном у меня есть план о том, как это сделать, и я могу воспользоваться некоторыми советами о том, является ли план вменяемым или нет :)

Обычно, когда вы отправляете в не-пустой репозиторий в git, его рабочая копия и индекс не обновляются. Как я обнаружил, это может вызвать серьезные проблемы, если вы забудете позже обновить их вручную!

В нашей группе у нас есть несколько «центральных» репозиториев, к которым люди клонируют и возвращают, но многие люди также хотят иметь возможность создавать клоны своих клонов и толкать / тянуть между ними по мере необходимости в истинно распределенном режиме. Чтобы сделать это безопасным, я хочу убедиться, что каждый репозиторий, созданный с помощью «clone» или «init», имеет автоматически установленный хук post-receive, который обновит рабочий каталог и индекс после операции push, чтобы синхронизироваться с новая ГОЛОВА.

Я обнаружил, что могу сделать это, создав каталог шаблонов с моим хуком post-receive в подкаталоге hooks, а затем заставив всех в моей группе сделать:

git config --global init.templatedir /path/to/template/dir

В настоящее время мой хук после получения выглядит так:

export GIT_WORK_TREE=..
git checkout -f HEAD

Это SEEMS для работы по желанию, но у меня есть некоторая неопределенность в отношении команды извлечения. Для целей синхронизации рабочего каталога и индекса с состоянием в HEAD эквивалентны "git checkout -f HEAD" и "git reset --hard HEAD"?

Я спрашиваю, потому что, хотя я знаю, что «git reset --hard HEAD» будет делать то, что я хочу, использование его в хуке post-receive значительно замедляет операции push в моем тестировании (кажется, делает новую проверку всех файлов, независимо от того, является ли файл грязным или чистым в рабочем каталоге). "git checkout -f HEAD" ВИДЕТЬ, чтобы сделать ту же самую вещь намного быстрее (получите мне чистый рабочий каталог и индекс, синхронизированный с HEAD), но я немного нервничаю, учитывая склонность команды checkout делать на лету сливается с незафиксированными изменениями рабочего каталога. Даст ли мне эта команда действительно рабочий каталог и индекс, которые точно соответствуют состоянию в HEAD во всех случаях (включая, например, удаление файлов, переименования и т. Д.)?

Заранее благодарю за любой совет!

Ответы на вопрос(2)

Ваш ответ на вопрос