Это означает, что он даже не выполняет ваш хук. Всякий раз, когда вы получаете такую ошибку, это может означать несколько вещей:
- Шебанг в верхней части вашего скрипта неверен. Возможно, в вашей системе нет оболочки BASH или что оболочка BASH находится в / usr / local / bin / bash или / usr / share / bin / bash. Вряд ли в системе Linux, но очень вероятно в Solaris. Проверьте это.
- В скрипте не установлен исполняемый бит. Вам нужно сделать
chmod +x
для вашего скрипта.
- Скрипт предварительной фиксации не может вызвать сам скрипт. Посмотрите на скрипт
pre-commit
внутри каталога hook и убедитесь, что он вызывает ваш скрипт. Или, что вы переименовали свой скрипт в pre-commit
и поместили его в этот каталог.
Другая возможность (более пристальное внимание к вашему сценарию) состоит в том, что вы перепутали сценарий pre-commit
BASH с pre-commit.bat
версией для оболочки Windows. Ваш синтаксис - оболочка Windows во второй половине сценария, но верхняя часть - оболочка BASH.
Вот мой хук предварительной фиксации . Это на Perl, поэтому он работает как с Windows, так и с Unix / Linux / Mac. Вам придется установить ActivePerl или Strawberry Perl на ваш компьютер с Windows, но оба они бесплатны и имеют открытый исходный код.
Мой сценарий предварительной фиксации может сделать несколько вещей, например, убедиться, что люди случайно не меняют теги, позволяя людям создавать теги, но не изменять их.
Мой скрипт также позволяет немного больше проверять с комментарием коммита. Например, вы используете систему отслеживания ошибок? Вы можете настроить мой хук так, чтобы в комментарии к коммиту требовался идентификатор отслеживания ошибок.
Другая возможность (и то, что я действительно рекомендую) - использовать инструмент непрерывной сборки, такой как Jenkins . Jenkins автоматически делает сборку и запускает тесты с каждым коммитом. Это гарантирует, что ошибки будут обнаружены раньше, чем постпроизводство.
Большим преимуществом Jenkins является то, что он представляет красивую веб-страницу со всей информацией, например, кто внес изменения и какие изменения они внесли. Разработчики находят это настолько полезным, что они автоматически начинают добавлять хорошие комментарии, не спрашивая. Удивительно, что я могу просмотреть журнал изменений Subversion и точно определить момент, когда я начал использовать Jenkins.
В вашем сценарии предварительной фиксации вы просто проверяете наличие пустых комментариев. Если вашим разработчикам не хочется добавлять комментарии, вы начнете получать комментарии, такие как changed code
и adaadsdasdasda
, просто чтобы выполнить коммит. С чем-то вроде Дженкинса, разработчики фактически начинают добавлять комментарии для коммитов самостоятельно.