Курс Git — Модуль 9: Инструменты и интеграции

Модуль 9: Инструменты и интеграции

Познакомимся с экосистемой вокруг Git: графические клиенты, SSH‑ключи, хуки и CI/CD. Плюс современные команды вместо старого checkout.

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

9.1 GUI‑клиенты

Sourcetree, GitKraken, Fork — визуальные клиенты для Git
Встроенные инструменты IDE (VS Code, JetBrains)

9.2 SSH‑ключи: генерация и добавление

# Сгенерировать ключ (современный ed25519)
ssh-keygen -t ed25519 -C "you@example.com"
# Добавить агенту (Windows с Git Bash / macOS / Linux)
ssh-add ~/.ssh/id_ed25519
# Показать публичный ключ и добавить на GitHub/GitLab
cat ~/.ssh/id_ed25519.pub

9.3 Git hooks: пример pre-commit

Хуки — скрипты в .git/hooks, которые запускаются на события Git.

# .git/hooks/pre-commit (Unix-подобные ОС)
#!/usr/bin/env bash
set -e

# Пример: запуск тестов
if [ -f "package.json" ]; then
  npm test
fi

# Пример: форматирование
if command -v prettier &>/dev/null; then
  npx prettier --check .
fi

Не забудьте сделать исполняемым: chmod +x .git/hooks/pre-commit. В командах используйте локальные dev‑зависимости.

Хуки — мощный, но локальный механизм. Для воспроизводимости в команде лучше использовать управляемые инструменты (например, pre-commit фреймворк) и проверки на CI.

9.4 CI/CD (на примере GitHub Actions)

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test --if-present

CI — это «сторож у ворот» вашей кодовой базы. Он должен быть быстрым, надёжным и прозрачным: понятные логи, стабильные окружения, детерминированные зависимости.

9.5 Современные команды: switch/restore

git switch -c feature/x вместо git checkout -b feature/x
git restore path вместо git checkout -- path

9.6 Несколько рабочих деревьев: git worktree

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

9.7 Подмодули: git submodule

Подмодуль — это ссылка на внешний репозиторий (фиксированный коммит) внутри проекта. Плюсы: независимые истории; минусы: сложнее онбординг, синхронизация версий и CI.

9.8 Встраивание историй: git subtree

subtree копирует историю зависимого проекта внутрь монорепо, упрощая работу без отдельного репозитория на продакшене. Проще, чем submodule, но история разрастается.

9.9 Большие файлы: Git LFS

Git LFS хранит бинарники как «указатели», сами файлы лежат во внешнем хранилище. Снижает размер репозитория, но требует серверной поддержки и квот. Подходит для медиа/датасетов.

9.10 Частичная выборка: sparse-checkout

Механизм выборочной materialization файлов/каталогов. В «cone mode» проще конфигурировать каталоги верхнего уровня. Полезно в монорепозиториях.

9.11 Поиск регрессий: git bisect

Двоичный поиск по истории определяет коммит, в котором возникла проблема. Теоретически снижает число проверок с O(N) до O(log N) по количеству коммитов.

9.12 Аннотация строк: git blame

Показывает, какой коммит последний изменил каждую строку. Учитывайте переименования/перемещения (опции обнаружения копий), чтобы не делать ложных выводов.

9.13 .gitattributes и драйверы диффов

Атрибуты управляют нормализацией перевода строк, бинарностью, стратегиями диффа/слияния и фильтрами. Примеры: text eol=lf, кастомные diff/merge‑драйверы.

9.14 Фильтры clean/smudge

Позволяют преобразовывать содержимое при записи/чтении (например, шифрование или форматирование). Нуждаются в аккуратной настройке и согласовании в CI.

9.15 Скоупы конфигурации Git

Конфигурация бывает системной, глобальной и локальной; доступны включения includeIf и «условные» настройки для разных директорий/проектов.

9.16 Подписанные коммиты (GPG/SSH): теория и настройка

Подпись коммита криптографически связывает автора и содержимое коммита. Провайдеры (GitHub/GitLab) валидируют подпись и показывают статус «Verified», что повышает доверие к истории и защищает от подделок.

GPG (OpenPGP)

Классический подход: создаётся пара ключей GPG, публичный ключ публикуется в профиле провайдера, приватный хранится у автора. Git использует GPG для подписания (gpg.program, user.signingkey).

# Создать ключ GPG
gpg --full-generate-key
# Показать публичный ключ (armor)
gpg --armor --export you@example.com
# Указать ключ Git-у
git config --global user.signingkey <KEYID>
# Включить подпись по умолчанию
git config --global commit.gpgsign true
# Подписать тег
git tag -s v1.0.0 -m "Release 1.0.0"

SSH-подписи

Современная альтернатива: используется уже существующая пара SSH‑ключей (например, ed25519). Провайдеры поддерживают валидацию SSH‑подписи, настройка проще на машинах без GPG.

# Включить подпись SSH (требует современного Git)
git config --global gpg.format ssh
# Указать SSH-ключ
git config --global user.signingkey ~/.ssh/id_ed25519.pub
# Подписать коммит
git commit -S -m "feat: подписанный коммит"

Git