идти Это отличный инструмент. Он позволяет не только отслеживать изменения в файле с помощью хуков, но и эффективно взаимодействовать с другими людьми. В этом отношении Git — один из инструментов, который продвинул разработку свободного и открытого программного обеспечения вперёд. Однако одна из самых больших проблем Git заключается в том, что управление репозиториями требует времени и усилий. Например, для фиксации и синхронизации этих репозиториев может потребоваться две-три команды git. Это делает управление ими не только утомительным, но и подверженным ошибкам пользователей. Здесь мы покажем вам несколько простых и эффективных хуков Git для более эффективного управления репозиториями.
Что такое Git-хуки?
git-hook — это, по сути, гибкая подкоманда, с помощью которой можно создавать пользовательские скрипты, запускаемые при выполнении Git каких-либо действий в репозитории. Например, вы можете использовать хук для автоматической проверки репозитория на наличие ошибок стиля перед его коммитом.
Подкоманда hook работает, считывая содержимое папки «hooks» в каталоге «.git» репозитория. Эта папка содержит ряд предварительно настроенных файлов, которые предоставляют скрипт для каждого действия Git, которое можно автоматизировать.
В большинстве случаев вы можете написать git-хук на любом удобном вам языке программирования. Это делает его невероятно гибким и удобным для любого разработчика.
1. Запретить отправку в мастер-версию
Одна из самых распространённых ошибок пользователей Git — отправка коммита из ветки разработки напрямую в ветку master. Это может быть невероятно утомительно, если вы используете GitHub для отслеживания и поддержки своих проектов.
Эту проблему можно предотвратить, создав предварительную отправку, которая будет проверять и подтверждать каждую попытку отправки репозитория из главной ветки.
- Перейти к Git-репозиторий Кого вы хотите защитить.
- Создавать Файл хука Git Используя программу аудита скриптов. Поскольку этот хук должен быть запущен до "толкать" , вам необходимо создать файл-хук. "Предоплата":
сенсорный .git/hooks/pre-push
- Открыть файл крючка Новое в Текстовый редактор.
nano .git/hooks/pre-push
- Внутри напишите Новый хук «до оплаты». Например, ниже приведен скрипт, который запросит у вас подтверждение при выполнении push-запроса из главной ветки:
#!/bin/sh protect='master' current=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,') if [ $protect = $current ] then read -p "Подтверждаете отправку на главный сервер? Y/n." -n 1 -r < /dev/tty echo if echo $REPLY | grep -E '^[Yy]$' > /dev/null then выход 0 fi выход 1 else выход 0 fi
- Сохранить Новый крючок. в карликовый Сделайте это, нажав Ctrl + O , Потом Ctrl + X.
- Выполните следующую команду, чтобы убедиться, что Git сможет запустить новый хук.
chmod +x .git/hooks/pre-push
2. Отклонять push-запросы в главную ветку
Помимо запрета на отправку изменений в мастер-ветку, вы также можете создать серверный хук, который будет отклонять любые отправки изменений в свою мастер-ветку. Это невероятно полезно, если вы делите репозиторий с несколькими разработчиками.
Исправьте это, создав хук «pre-receive», который автоматически предотвратит отправку изменений в главную ветку любым ограниченным пользователем.
- Создавать Файл хука Git для «предварительного получения» На вашем удаленном складе.
сенсорный .git/hooks/pre-receive
- открыть это файл.
nano .git/hooks/pre-receive
- Добавить текст отказа в крючок "предварительная расписка"Например, следующие строки кода должны работать сразу:
#!/bin/sh branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,') blacklist=(alice bob) if [[ ${blacklist[*]} =~ $USER ]]; then if [ "$branch" == "master" ]; then echo "Вам не разрешено фиксировать изменения в этой ветке" exit 1 fi fi - Сохраните новый файл хука. В моём случае нужно нажать Ctrl+O, а затем Ctrl+X, чтобы сохранить файл.
- Сохранить текст крючка Сделайте его своим и примените на практике.
chmod +x .git/hooks/pre-receive
Совет: вы также можете использовать псевдоним Git, чтобы сделать использование Git более эффективным.
3. Заблокируйте возможность перебазирования репозитория.
Другая распространённая ошибка пользователей Git — это перебазирование текущей активной ветки. Это может быть неприятно, если вы работаете с репозиторием с несколькими участниками, поскольку перебазирование удалит коммиты, сделанные другими пользователями.
Эту проблему можно предотвратить, создав хук «pre-rebase», который будет проверять, закрыта ли текущая ветка или нет.
- созданный файл предварительной перебазировки В руководстве «.git/hooks»:
сенсорный .git/hooks/pre-rebase
- открыть это Файл для редактирования.
nano .git/hooks/pre-rebase
- Добавить сценарий перебазировать внутри Новый файл-хук.
#!/bin/sh branch="$2" [ -n "$branch" ] || branch=$(git rev-parse --abbrev-ref HEAD) lock="branch.${branch}.rebaselock" if [ "$(git config --bool "$lock")" = true ]; then echo "pre-rebase hook: “$lock” установлен в значение true. Отказ от rebase." exit 1 fi - Сохранить файл крючка Новое и сделайте его осуществимым.
chmod +x .git/hooks/pre-rebase
4. Принудительно проверяйте стиль и синтаксис вашего кода
Одно из самых полезных применений Git-хука — присоединение его к линтеру кода. Это простая программа, которая проверяет, соответствует ли ваш код стилю и формату проекта.
- Для подключения ЛИНТЕР Сначала создайте файл привязки в вашем Git-репозитории. «Предварительное обязательство».
сенсорный .git/hooks/pre-commit
- установить ЛИНТЕР Подходит для вашего проекта. В данном случае я использую «проверка оболочки» Чтобы проанализировать мой код Bash:
sudo apt установить shellcheck
- Открыть файл крючка Создайте новый и добавьте следующий скрипт.
#!/bin/bash for file in $(git diff --cached --name-only --diff-filter=AM | grep -E '\.sh$') do shellcheck "$file" # Запустить linter для каждого нового файла. if [$? -ne 0 ]; then exit 1 # Прервать фиксацию, если linter завершился неудачей. fi done
- Сохранить файл крючка Создайте новый и сделайте его исполняемым:
chmod +x .git/hooks/pre-commit
5. Автоматически уведомлять пользователей об изменениях в репозитории
Наконец, вы также можете создать Git-хук, который будет автоматически отправлять электронное письмо при каждом поступлении в ваш репозиторий нового коммита. Это полезно, если вы хотите создать простую систему уведомлений для своего репозитория.
- Создавать Файл хуков «пост-приемник» В руководстве .git/hooks На вашем складе:
сенсорный .git/hooks/post-receive
- Открыть Файл хука Git Создайте новый и введите следующий скрипт:
#!/bin/sh commit_message=$(git log -1 --pretty=%B) users=("[электронная почта защищена]""[электронная почта защищена]""[электронная почта защищена]") для пользователя в "${users[@]}"; сделать mail -s "Новый коммит: $commit_message" $user < /dev/null done - Сохранить файл крючка Новое и сделайте его осуществимым.
chmod +x .git/hooks/post-receive
Часто задаваемые вопросы
В1. Могу ли я писать Git-хуки на компилируемом языке, например C?
отвечать. Одно из самых больших ограничений Git-хуков заключается в том, что они требуют использования языка, который можно запустить непосредственно из терминала. Это означает, что Git-хуки не поддерживают компилируемые языки для своих скриптов. Например, вы можете создавать новые Git-хуки на Python или в оболочке, но не на C или C++.
В2. Можно ли запустить несколько хуков в одном репозитории Git?
отвечать. Да. Хотя в примерах выше хуки показаны как отдельные функции, вы можете легко объединить их для создания собственного уникального рабочего процесса, что делает хуки Git невероятно гибкими и адаптируемыми к любой ситуации. Например, вы можете использовать в своём репозитории как хук «Prevent Push to Master», так и хук precommit «Syntax Check».
В3. Почему хуки Git не отправляют электронные письма пользователям?
отвечать. Эта проблема, скорее всего, вызвана тем, что ваш удалённый сервер не может корректно отправлять исходящие письма. Чтобы исправить это, убедитесь, что ваш удалённый сервер защищён и на нём установлен почтовый агент, работающий совместно с доменом SMTP.
