Как облегчить рабочий процесс разработки вашей команды с помощью Git Hooks

Одним из основных требований при работе в команде или над проектом с открытым исходным кодом является использование системы контроля версий (VCS). Git — это бесплатная распределенная система контроля версий с открытым исходным кодом для отслеживания изменений исходного кода во время разработки программного обеспечения. Он был создан Линусом Торвальдсом в 2005 году для разработки ядра Linux. Он прост в освоении и имеет крошечный размер с молниеносной производительностью.

Есть большая вероятность, что вы уже использовали Git (поскольку это один из самых популярных и хорошо принятых инструментов VCS, доступных в сообществе разработчиков), и у вас, скорее всего, уже есть некоторые знания о подготовке и фиксации вашего кода путем отправки и получения кода. это из удаленного репозитория. В этой статье не рассматриваются основы рабочих процессов git, но основное внимание будет уделено git hooks и тому, как их использовать для улучшения совместной работы в вашей команде. По мере того, как команды растут в размерах, становится еще более важным держать участников в узде и поддерживать разные правила в отношении кода.

Что такое Git-хуки?

Git-хуки — это скрипты, которые запускаются, когда в репозитории git выполняются определенные действия или события. Эти действия относятся к частям рабочего процесса управления версиями, таким как фиксация и отправка. Хуки могут быть очень полезны, автоматизируя задачи в рабочем процессе git. Например, они могут помочь нам проверить синтаксис нашей кодовой базы на основе определенных правил или выполнить некоторые тесты перед фиксацией наших изменений.

Как их установить?

Git-хуки — это встроенная функция, что означает, что мы можем получить к ним доступ и начать использовать их, пока репозиторий git инициализирован. Давайте посмотрим более подробно, что это значит, попробовав их установить.

Используя ваш любимый терминал, создайте новый репозиторий git.

 mkdir my-new-repository && cd my-new-repository git init ls -la

Вы заметите, что только что был создан новый скрытый каталог. Эта папка .git используется из git для хранения информации, связанной с репозиторием, такой как хэши контроля версий, информация о коммитах, адреса удаленного репозитория и т. д. Это также папка, где на самом деле живут хуки для git .git/hooks . Вы можете найти некоторые предварительно заполненные примеры сценариев, автоматически созданные во время инициализации. На самом деле это сценарии, которые будут запускаться после определенных действий.

 ls .git/hooks

Вот некоторые образцы, которые вы можете найти:

• pre-commit.sample : вызывается непосредственно перед фиксацией.
• commit-msg.sample : отредактируйте файл сообщения на месте.
• post-receive.sample : вызывается после обновления удаленного репозитория.

Под капотом

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

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

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

Всякий раз, когда мы фиксируем какие-либо изменения в нашей кодовой базе, некоторые из этих связанных хуков срабатывают в следующем порядке:

1. pre-commit : проверяет моментальный снимок, который должен быть зафиксирован, и проверяет, что должно быть зафиксировано.
2. prepare-commit-msg : позволяет редактировать сообщение по умолчанию до того, как его увидит автор фиксации.
3. commit-msg : устанавливает сообщение фиксации в шаблон.
4. post-commit : запускает действие сразу после завершения фиксации и, например, отправляет уведомление.

Теперь давайте попробуем добавить в приведенный выше репозиторий несколько пользовательских сценариев до и после фиксации, чтобы лучше представить, как на самом деле работают git-перехватчики.

 nano .git/hooks/pre-commit

Добавьте следующий фрагмент:

 #!/bin/sh echo Changes are about to be committed

Убедитесь, что наши скрипты исполняемые:

 chmod +x .git/hooks/pre-commit

Повторите описанный выше процесс для сценария post-commit :

 nano .git/hooks/post-commit

 #!/bin/sh echo Changes have been committed

 chmod +x .git/hooks/post-commit

Теперь мы можем добавить новый файл nano index.html с небольшим фрагментом HTML только для демонстрационных целей (не нужно сообщать об этом валидаторам HTML).

 <h1>Hello world from our new repository!</h1>

Мы добавим изменения в нашу кодовую базу посредством подготовки, а затем зафиксируем это:

 git add . git commit

После того, как фиксация была успешно обработана, мы можем увидеть следующий вывод двух добавленных выше скриптов:

 Changes are about to be committed Changes have been committed

Как и ожидалось, git активировал хуки в потоке коммитов. Добавленные сценарии pre-commit и post-commit запущены и будут выполняться в правильной последовательности (в соответствии с упомянутым ранее порядком).

Это была простая демонстрация, чтобы понять, как работают сценарии рабочего процесса фиксации и как они выполняются. Подробнее об этом рабочем процессе можно прочитать в документации.

В приведенном выше примере мы решили написать эти два сценария на bash, но правда в том, что git поддерживает хуки, которые можно написать на любом языке сценариев, который мы захотим. Ruby, Python или JavaScript — отличные альтернативы, если мы устанавливаем правильный шебанг в первой строке нашего исполняемого скрипта.

Например, мы можем переписать хук pre-commit в виде скрипта Node.js, как показано ниже:

 #!/usr/bin/env node console.log("Changes are about to be commited")

Локальные и удаленные хуки

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

Локальные крючки

• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• applypatch-msg
• pre-applypatch
• post-applypatch
• pre-rebase
• post-rewrite
• post-checkout
• post-merge
• pre-push

Удаленные хуки

• pre-receive
• update
• post-receive

Обмен хуками

Git-хуки предназначены для того, чтобы делиться ими внутри команды. Это основная причина, по которой они существуют: содействие лучшему сотрудничеству в команде, автоматизация вредных процессов и предоставление нам возможности сосредоточиться только на важных частях кодовой базы.

Как указывалось ранее, .git/hooks — это папка, в которой размещаются наши настроенные хуки, но это не очень полезно, когда нам нужно поделиться этими сценариями в команде, поскольку эта папка не отслеживается git.

Хороший подход для решения этой проблемы — добавить все наши пользовательские хуки в отдельную папку внутри нашего репозитория. Например, мы можем добавить папку .githooks и сохранить там исполняемые скрипты. Затем, при инициализации проекта, мы можем либо явно скопировать, либо создать символическую ссылку на эти скрипты в исходную папку, чтобы сохранить наши хуки .git/hooks .

 find .git/hooks -type l -exec rm {} \\; find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \\;

В качестве альтернативы, если вы используете последнюю версию git (имеется в виду 2.9 и выше), мы можем напрямую настроить путь git hooks к нашей пользовательской папке:

 git config core.hooksPath .githooks

Git Hooks Made Easy (пример использования кода JavaScript)

Существуют инструменты, которые помогают нам дополнительно интегрировать git-хуки в соответствии с потребностями нашей кодовой базы. Специально для кодовых баз JavaScript существует Husky, с помощью которого мы можем легко настроить действия для событий git посредством конфигурации.

Например, мы можем легко выполнить линтинг нашего кода или запустить некоторые тесты в событии pre-commit и продолжить фиксацию в зависимости от того, были ли линтинг, тестирование или и то, и другое успешными или нет.

Этого можно добиться, расширив конфигурацию package.json следующим образом:

 { "scripts": { "test": "echo Running tests" }, "devDependencies": { "eslint": "5.16.0", }, "husky": { "hooks": { "pre-commit": "eslint . && npm test", } } }

Заключение

В этой статье мы узнали, что различные действия, выполняемые в репозитории git, могут дополнительно запускать пользовательские сценарии. Эти сценарии могут находиться под контролем разработчика локально или более централизованно для команды или удаленного проекта. Мы также узнали, что сценарии часто пишутся на языке оболочки, таком как bash, но на самом деле могут использовать практически любой язык сценариев, даже JavaScript.

Git-хуки могут быть действительно мощной частью хорошо спроектированного рабочего процесса, и я рекомендую вам попробовать их и посмотреть, что вы можете сделать для своих собственных проектов.