Java, UX, HTML, CSS, WEB-design

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

[ad_1]

  • Константинос Леймонис

  • 0 Комментарии

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

  • 8 минут чтения

  • Инструменты, Методы, Рабочий процесс, Git

Краткое резюме ↬

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

Одним из основных требований при работе в команде или над проектом с открытым исходным кодом является использование системы контроля версий (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: запускает действие сразу после завершения фиксации и, например, отправляет уведомление.

Хуки, выполняемые в процессе создания коммита

Хуки, выполняемые в процессе создания коммита (Изображение предоставлено Atlassian Bitbucket) (Большой предварительный просмотр)

Теперь давайте попробуем добавить в приведенный выше репозиторий несколько пользовательских сценариев до и после фиксации, чтобы лучше представить, как на самом деле работают 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-хуки могут быть действительно мощной частью хорошо спроектированного рабочего процесса, и я рекомендую вам попробовать их и посмотреть, что вы можете сделать для своих собственных проектов.

Сокрушительная редакция
(дм, ил)



[ad_2]
Source: https://smashingmagazine.com

Заключение

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

Пожалуйста оцените статью, и напишите комментарий.

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован.

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

Название: Как облегчить рабочий процесс разработки вашей команды с помощью Git Hooks . Краткое описание: [ad_1] ⭐ Констан . Дата публикации: 22.01.2022 . Автор: Алишер Валеев .

Для чего создан сайт Novosti-Nedeli.ru

Данный сайт посвящен новостям мира и мира технологий . Также тут вы найдете руководства по различным девайсам.

Сколько лет сайту?

Возраст составляет 3 года

Кнопка «Наверх»