Git: безопасное создание репозиториев

Question

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

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

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

Я обнаружил, что могу это сделать, создав каталог шаблонов с моим ловушкой 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"?

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

Заранее спасибо за любой совет!

Answer 1

Возможно, я неправильно понял проблему.Вы действительно хотите настроить его так, чтобы любой мог перейти в рабочий каталог разработчика, пока у него есть незафиксированные изменения, над которыми он работает?Это не может быть сделано «безопасным» с помощью любого отрезка слова.

То, что делает большинство людей, - это имеет свой обычный рабочий каталог, который является частным, и превращает его в публичный репозиторий на публичном репозитории.тот же диск, и поделиться этим.При этом используются жесткие ссылки, поэтому вы едва используете дополнительное пространство.Вы помещаете свои изменения в общедоступное репо своего коллеги, и он начинает работать в своем рабочем каталоге, когда готов принять изменения.С другой стороны, вы вносите свои изменения в ваше публичное репо, и ваш коллега отстает оттуда, когда он будет готов.Есть причина, по которой трудно установить репозитории, не являющиеся открытыми.

Answer 2

Я предлагаю использовать post-update hook , указанный в Git FAQ entry » Почему я не вижу изменений в удаленном репо после« git push »? ”.

Он будет скрывать поэтапные и неустановленные изменения (в отслеживаемых файлах) перед выполнением аппаратного сброса.Это безопаснее, чем обычная полная перезагрузка, но, как говорится в записи часто задаваемых вопросов, она все еще не охватывает все ситуации, которые могут возникнуть (например, индекс с существующим конфликтом не может быть сохранен; он не выполняет автоматическое объединение измененийна немодифицированные файлы, такие как git checkout делает и т. д.).

---

Однако…
, если это вообще возможно,…
вам, вероятно, следует просто избегать нажатия на любую извлеченную ветку впервое место.

Пересылка в не-пустой репозиторий - это нормально, если вы не продвигаетесь в извлеченную ветку (в конце концов, задействованная переменная конфигурации - receive.denyCurrentBranch, а не «receive.denyNonBare»).

В последнем абзаце вышеупомянутой ссылки на часто задаваемые вопросы есть ссылки (как в комментарии ниже, Марк Лонгэйр упоминает) еще одна запись , в которой описывается подход к толкованию непонятногорепозиторий.Мотивация для записи - асимметричное сетевое соединение между двумя непокрытыми репозиториями, но этот метод может быть применен к любой ситуации, когда вам нужно / нужно перейти в непустое хранилище.

Эта последняя запись часто задаваемых вопросовдает пример отправки в ветку удаленного слежения (под refs/remotes/).Только ссылки под refs/heads/ могут быть проверены без отсоединения HEAD (без использования git symoblic-ref), поэтому нажатие на что-либо за пределами refs/heads/ должно быть безопасным, чтобы избежать «подталкивания к проверенной ветви».

Поскольку вы работаете в централизованной среде, вы можете составить политику для назначения таких отправлений.Например:

Когда вам нужно отправить коммиты в чей-то не-пустой репозиторий, переместите их в refs/remotes/from/<your-username>/<branch>.Чтобы избежать конфликтов с обычными ветвями удаленного отслеживания, никто не должен определять пульт с именем from.Ответвленные ветки будут отображаться в git branch -a (или -r) и, соответственно, на них можно ссылаться без префикса refs/remotes/.Однако псевдодистанция from не будет отображаться в git remote, так как нет переменной конфигурации remote.from.url.

Пример:

alice$ remote add betty bettys-machine:path/to/some/non-bare/repository
alice$ git push betty master:refs/remotes/from/alice/bug/123/master

betty$ git log --reverse -p origin/master..from/alice/bug/123/master