Отслеживание изменений хуков в .git / hooks

Есть ли способ отслеживать изменения хуков git? У меня есть три перехватчика, которые появляются только на моей машине, а не при загрузке других разработчиков. Попытка git add не работает.


person Hans    schedule 16.12.2010    source источник
comment
Я бы тоже хотел получить ответ на этот вопрос! Я не могу отправить описание на свой веб-сервер. Я видел предложения использовать символическую ссылку в контролируемом каталоге, указывающую на файл в .git, но я не мог заставить ее работать   -  person Robert    schedule 16.12.2010
comment
возможный дубликат Можно ли управлять сценариями перехвата Git вместе с репозиторий?   -  person Cascabel    schedule 16.12.2010
comment
Я проголосовал за закрытие, установив самый старый точный дубликат. Вот еще два: stackoverflow.com/questions/2050450/git-hooks-management и stackoverflow.com/questions/3462955/ Общее предложение состоит в том, чтобы создать символические ссылки на хуки, либо весь каталог, либо один за другим более изящным способом, как я предлагал во второй из этих двух ссылок.   -  person Cascabel    schedule 16.12.2010
comment
Я использовал символическую ссылку, но для начальных клонов сначала необходимо выполнить настройку. Не конец света, но, похоже, это было бы неплохо.   -  person Hans    schedule 16.12.2010
comment
Вот почему вы помещаете сценарий, который позаботится об этом, в репозитории, так что это всего лишь один шаг после клонирования.   -  person Cascabel    schedule 16.12.2010
comment
Пункт, который ИМО следует прояснить относительно вышеупомянутого обсуждения; Необходимость ручного шага после клонирования перед включением перехватчиков определяется ДИЗАЙНОМ. Автоматическая установка произвольного кода для запуска только в результате клонирования представляет собой огромный риск для безопасности.   -  person Mark Adelsberger    schedule 22.10.2019


Ответы (6)


http://benjamin-meyer.blogspot.com/2008/10/git-hooks.html < / а>

Файлы в каталоге .git / hooks не являются частью репозитория и поэтому не отслеживаются. Обходной путь - иметь каталог git_hooks в верхней части вашего репозитория, как это сделано в Arora, и символическую ссылку .git / hooks на git_hooks всякий раз, когда вы клонируете. Таким образом, хуки станут частью проекта, находятся под контролем редакции и будут доступны всем.

person Brian Clapper    schedule 16.12.2010

Я понимаю, что этому вопросу много лет, но я чувствую, что это нужно сказать путешественникам, подобным мне, которые попадают сюда: крючки не отслеживаются по замыслу! Ответ Брайана будет работать, но дело в том, что вы фактически доверяете всем остальным, с кем работаете, не помещать вредоносный код в репозиторий, который ваши хуки затем без вопросов выполняют; это само определение дыры в безопасности.

person Philip Adler    schedule 20.05.2014
comment
Хорошая точка зрения! Но это можно решить, поместив этот git_hooks каталог в совершенно отдельный проект и разрешив репо только тем людям, которые обладают достаточными знаниями и несут ответственность за изменения. - person sobi3ch; 03.04.2015
comment
Я все время бегаю rake spec и верю, что не работаю с каким-то психопатом, который поместил system("rm -rf / --no-preserve-root") в Rakefile. Я не понимаю, чем по-другому доверять моим соавторам в том, что они не использовали вредоносный код для хуков git ... - person lamont; 19.08.2016
comment
@lamont иногда код является вредоносным, а программист - нет. Если вы чувствуете, что можете до такой степени доверять людям, с которыми работаете, тогда отлично, но это не меняет того, что крючки не отслеживаются по дизайну и по этой причине. - person Philip Adler; 19.08.2016
comment
я понимаю, что код, зарегистрированный в репозитории, может быть вредоносным. Я запустил модульные тесты, которые запустили FileUtils.rm_rf(".") в моем репо и полностью уничтожили мое локальное дерево (и могли легко уничтожить мой домашний каталог). Мой аргумент заключается в том, что git-hooks не более привилегированы, чем любые другие тысячи и тысячи строк кода в репозитории, который я запускаю ежедневно. Все это может испортить мне день. Можете ли вы объяснить фундаментальную разницу между хуками git и моими фреймворком и тестами для модульного тестирования? - person lamont; 24.08.2016
comment
Фактически, они более привилегированы в том смысле, что в некоторых случаях перехватчики запускаются автоматически, прежде чем вы сможете исследовать их как часть процесса извлечения кода - в отличие от любого другого компонента, который вы упомянули. - person Philip Adler; 27.09.2016
comment
@PhilipAdler: хуки не будут выполняться, если вы не выполните никаких других действий, кроме извлечения кода из репозитория. Более того, решение @BrianClapper требует, чтобы вы скопировали или связали каталог git_hooks. Перед этим вы ДОЛЖНЫ проверить его содержимое. При этом нет ничего неконтролируемого. - person Damien Flament; 15.06.2017
comment
@DamienFlament Мне дали понять, что это верно только для первого клона. После этого код можно изменить, и при условии, что каталог не удален, вам не нужно повторно проверять код. Первая часть вашего комментария верна ... но тогда зачем вообще крючки, если вы только тянете? - person Philip Adler; 18.06.2017
comment
@PhilipAdler: Я не говорю, что нужно вытаскивать только код! Я только что указал, что операции «только извлечение» не активируют хуки git. Таким образом, вы можете без всякого риска проверить содержимое хуков перед их копированием. Но это правда, что потом крючки можно будет модифицировать. Так что связывание их кажется опасным. Но копирование не опасно, пока вы их проверяете заранее. - person Damien Flament; 19.06.2017
comment
Да, это нормально. - person Philip Adler; 07.07.2017

Возродив этот старый поток, у вас может быть отдельный каталог с контролируемой версией, содержащий ваши хуки, а затем использовать git config core.hooksPath для таргетинга на этот каталог.

person Maj. Dave    schedule 25.09.2017
comment
тогда как сделать так, чтобы кто-нибудь в команде выполнил эту настройку перед коммитом кода? - person TangHongWan; 10.04.2019
comment
@PageNotFound, вы помещаете инструкции в README проекта, а также добавляете этап линтинга к этапу в конвейере, на случай, если кто-то забудет, он получит напоминание о сбое сборки. Не идеально, но на практике работает отлично. - person emerino; 01.05.2020

Изменение ответа Брайана, чтобы учесть важный момент Филиппа:

Если у вас есть пользователь с доступом на запись, который создает перехватчик (скажем, после фиксации) с помощью '#! / Bin / sh rm -rf ~', он переходит в ваш домашний каталог. (Или, может быть, что-то более мягкое, но все же глупое.)

Чтобы защититься от этого, было бы лучше не создавать символические ссылки на каталог, а вручную копировать их в каталог git_hooks и из него. Да, вы должны не забыть вручную копировать эти файлы при их обновлении, но лучше, чем ничего, и тем не менее вы не предоставляете кому-либо доступ к командам на вашем компьютере на уровне пользователя.

ОБНОВЛЕНИЕ: как упоминалось ниже, если вы планируете менять свои хуки в кучу, вы можете создать сценарий оболочки, который копирует файлы, а затем запускает фиксацию. Однако автоматизация фиксации (с помощью git add и ввода автоматического сообщения) действительно беспорядочная. Лучшей идеей было бы, чтобы один из ваших хуков делал копию в этот каталог 'git_hooks' перед фиксацией. Таким образом, злоумышленник не сможет зафиксировать файл, который будет запущен при следующем вызове ловушки.

person jpmorris    schedule 09.03.2015
comment
вам не нужно ничего запоминать :) просто используйте скрипт сборки. Затем вы можете создать символическую ссылку или скопировать или что-то еще, если у вас другая идея. - person sobi3ch; 03.04.2015

Другим решением (не связанным с отслеживанием / управлением версиями) может быть использование плагина, который будет обрабатывать хуки за вас.

Например: в случае веб-приложения представьте, что вы можете добавить один скрипт в пакет json, который будет настраивать перехватчики перед фиксацией!

Вот хороший пример: https://github.com/typicode/husky

В конце концов, этот скрипт может находиться под контролем версий, и вам не нужно иметь дело с папкой хуков внутри .git.

person Frix G    schedule 29.03.2018

Используйте каталоги шаблонов. Из клона git вы можете использовать флаг --template=<template_directory> для добавления файлов в $GIT_DIR. Вам также нужно будет создать каталог, в котором будет храниться ваш шаблон, или использовать gits, указанное в местоположении /usr/share/git-core/templates. Используя каталог шаблонов, вы можете иметь активную ловушку, готовую к запуску в директории хуков с момента создания.

Я не уверен, как часто ваши люди будут вносить правки, но вы можете сохранить этот шаблон в репозитории, к которому у всех есть доступ. На самом деле это должен быть один перехватчик, который запускает файл в репозитории, содержащий весь код, который вам нужен для автоматического запуска.

Как уже упоминалось другими, как только вы автоматически запускаете неизвестный код, вы подвергаетесь риску.

person Ace    schedule 15.08.2015