Настройка и интеграция распределённого контроля версий Git с LFS, GPG‑подписями и хуками в среде Termux

Termux стал популярным инструментом для мобильной работы с репозиториями, прототипирования и полевых задач. Однако полноценный workflow с Git на практике требует дисциплины: больших файлов через Git LFS, криптографической достоверности через GPG‑подписи и автоматического контроля через хуки. В этой статье рассмотрим, как выстроить безопасную и предсказуемую цепочку изменений в среде Termux, сохранив совместимость с настольными Git‑клиентами и серверной инфраструктурой.

Подготовка Termux и базовая настройка Git

Начнём с установки пакетов. В зависимости от версии Termux/репозиториев названия могут немного отличаться, но логика сохраняется.

pkg update && pkg upgrade
pkg install git gnupg git-lfs openssh

Проверьте версии:

git --version
git lfs version
gpg --version

Далее задайте идентичность автора. Это важно для согласования GPG‑подписей и отображения автора в истории коммитов:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

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

Инициализация репозитория и подключение Git LFS

Git LFS нужен, когда в проекте появляются крупные бинарные файлы (медиа, обучающие модели, артефакты сборки), чтобы основной репозиторий не раздувался. Предпочтительный подход — настроить LFS на уровне репозитория так, чтобы правила были одинаковыми у всех участников.

Если репозиторий ещё не создан:

mkdir myrepo && cd myrepo
git init

Подключите LFS:

git lfs install

Выберите типы файлов, которые должны храниться в LFS, и добавьте фильтры. Например:

git lfs track ".psd"
git lfs track ".zip"
git lfs track ".mp4"
git lfs track ".bin"

После этого появится файл .gitattributes. Его нужно закоммитить:

git add .gitattributes
git commit -m "Configure Git LFS tracking"

Проверьте, что правила применяются:

git lfs ls-files

Важно: Git LFS включается в коммит-потоке через атрибуты. Это обеспечивает предсказуемость для CI и других клиентов.

Настройка GPG для подписи коммитов

GPG‑подписи повышают доверие к истории: участник доказывает, что коммит подписан именно его ключом. В контексте совместной разработки это особенно полезно при разборе инцидентов, аудите изменений и расследовании происхождения артефактов.

Сначала определите, где хранить ключи и какой агент использовать. В Termux обычно достаточно стандартного gpg и корректной интеграции через gpg-agent. Проверьте, есть ли агент:

gpgconf --list-dirs

Создайте ключ. Практика безопасности: выбирайте надёжный алгоритм и задавайте парольную фразу (не оставляйте ключ “пустым”).

gpg --full-generate-key

В мастере обычно удобны параметры по умолчанию, но рекомендации:

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

Получите идентификатор ключа (key ID или fingerprint):

gpg --list-secret-keys --keyid-format=long

Настройте Git на использование GPG и подпись всех коммитов:

git config --global user.signingkey "YOUR_KEY_ID"
git config --global commit.gpgsign true

Проверьте, как Git обращается к программе подписи:

git config --global gpg.program "gpg"

Создайте тестовый коммит с подписью и проверьте:

git commit -m "Signed commit test" --allow-empty
git log --show-signature -1

Если проверка показывает “Good signature”, базовая связка работает.

Публикация публичного ключа для верификации

Чтобы сервер (GitHub/GitLab/внутренний Git) мог верифицировать подписи, публикуйте публичную часть ключа. Экспорт:

gpg --armor --export "YOUR_KEY_ID" > public-gpg-key.asc

Дальше загрузите public-gpg-key.asc в настройки аккаунта/организации. Для внутреннего репозитория — введите ключ в соответствующий механизм управления доверенной подписью.

Внедрение Git хуков в репозитории Termux

Хуки — это автоматические проверки, которые запускаются при выполнении операций Git в локальной рабочей копии. В рамках темы “распределённого контроля версий” хуки помогают гарантировать минимальные требования качества: форматирование, запреты на коммиты “сырья”, контроль LFS‑загрузок, подтверждение наличия подписи и корректного сообщения коммита.

В Git существует каталог .git/hooks. Важное правило: хуки не коммитятся автоматически. Рекомендуется хранить шаблоны хуков в отдельной папке репозитория и разворачивать их скриптом, либо использовать средства шаблонов. Ниже приведём практичный вариант: добавим хук-скрипты через install в репозитории.

Хук для проверки наличия GPG‑подписи

Если у вас политика требует подпись каждого коммита, можно запретить “несигнатурные” коммиты. Самый надёжный момент — pre-commit либо commit-msg. Однако проверка подписи в pre-commit может зависеть от состояния индекса, поэтому чаще используют политику проверки в commit-msg и/или используют pre-rebase, где уже есть коммиты.

Вариант: проверять, что коммит будет с подписью. Так как Git уже настроен commit.gpgsign=true, это защищает большинство случаев, но хук даёт дополнительную страховку при ручных override.

Создайте в репозитории скрипт установки хуков:

mkdir -p .githooks
cat > .githooks/install.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/sh
set -e

HOOKS_DIR=".git/hooks"

mkdir -p "$HOOKS_DIR"

# commit-msg: проверка наличия опции подписи через состояние конфигурации
cat > "$HOOKS_DIR/commit-msg" <<'EOT'
#!/data/data/com.termux/files/usr/bin/sh
set -e

# Если коммит делается без подписи (например, кто-то переопределил commit.gpgsign),
# Git в некоторых случаях всё равно позволит коммит. Поэтому оставим доп. проверку.
# Базовая эвристика: проверяем, что gpgsign включен.

value=$(git config --bool commit.gpgsign || echo false)
if [ "$value" != "true" ]; then
  echo "ERROR: commit.gpgsign is not enabled in this repository/user config."
  echo "Refusing to create an unsigned commit."
  exit 1
fi

exit 0
EOT

chmod +x "$HOOKS_DIR/commit-msg"
EOF

chmod +x .githooks/install.sh
./.githooks/install.sh

Этот хук не анализирует уже готовую подпись конкретного объекта (что сложнее на этапе commit-msg), но предотвращает сценарии, когда политика была “выключена” настройками. Для строгой проверки подписей обычно лучше дополнительно держать server-side enforcement (например, в CI).

Хук для контроля Git LFS: запрет “прямых” больших файлов

Чтобы исключить случайное добавление бинарников напрямую в Git вместо LFS, полезно проверять размер staged‑файлов. Хук pre-commit можно настроить так, чтобы он отказывал, если размер превышает порог и файл не покрыт правилами LFS.

Создадим хук pre-commit:

cat > .githooks/install-lfs-precommit.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/sh
set -e

HOOKS_DIR=".git/hooks"

cat > "$HOOKS_DIR/pre-commit" <<'EOT'
#!/data/data/com.termux/files/usr/bin/sh
set -e

# Порог можно настроить под вашу инфраструктуру.
LIMIT_BYTES=10485760  # 10 MiB

# Получаем staged файлы.
files=$(git diff --cached --name-only --diff-filter=ACM)

# Если ничего не добавлено/изменено — выходим.
if [ -z "$files" ]; then
  exit 0
fi

fail=0

for f in $files; do
  # Игнорируем директории
  if [ -d "$f" ]; then
    continue
  fi

  if [ ! -f "$f" ]; then
    continue
  fi

  size=$(wc -c < "$f" | awk '{print $1}')

  # Проверка порога
  if [ "$size" -gt "$LIMIT_BYTES" ]; then
    # Определяем, подпадает ли файл под LFS правила.
    # git lfs track использует .gitattributes, так что проверяем матчинг через git lfs.
    # Команда может зависеть от версии; эвристика: если для файла не находится lfs-обработка,
    # будем считать это ошибкой.
    
    # Вариант эвристики: проверяем атрибут фильтра через git check-attr.
    attr=$(git check-attr filter -- "$f" | awk '{print $3}')

    # Если атрибут не "lfs" (или не совпадает с вашей настройкой), запретим.
    # Для Git LFS атрибут обычно имеет вид: filter: lfs
    if [ "$attr" != "lfs" ] && [ "$attr" != "" ]; then
      echo "ERROR: '$f' is staged and exceeds $LIMIT_BYTES bytes, but is not configured for Git LFS."
      fail=1
    elif [ "$attr" = "unspecified" ] || [ "$attr" = "" ]; then
      echo "ERROR: '$f' is staged and exceeds $LIMIT_BYTES bytes and likely is not configured for Git LFS."
      fail=1
    fi
  fi

done

if [ "$fail" -eq 1 ]; then
  echo "Commit aborted. Configure the file pattern in .gitattributes via git lfs track."
  exit 1
fi

exit 0
EOT

chmod +x "$HOOKS_DIR/pre-commit"
EOF

chmod +x .githooks/install-lfs-precommit.sh
./.githooks/install-lfs-precommit.sh

Доработки под ваши атрибуты возможны: если у вас отличные правила или другие атрибуты, настройте проверку. Главная идея — не допустить случайный “вброс” больших файлов в обычный Git‑объектный слой.

Практика: проверка подписей и LFS перед пушем

Перед тем как отправлять изменения в удалённый репозиторий, полезно прогнать быструю проверку:

git status
git lfs status
git log --show-signature -1

Если используете ветвление, валидацию можно расширить на диапазон коммитов. Пример: просмотр подписей последних N:

git log --show-signature -n 10

Для LFS можно также убедиться, что нужные объекты загружены (команды зависят от версии, но базовый принцип — держать согласованность между pointer‑файлами и реальными LFS‑объектами).

О вариантах сетевой доступности

Если вам требуется подключение к удалённым ресурсам из поля, иногда удобна организация локальной сети (например, через VPN для создания локального сегмента). В контексте этой статьи такие решения рассматриваются только как средство сетевой связности, без целей обхода ограничений доступа. Для стабильности рекомендуется использовать надёжное подключение и фиксировать адреса/порты, принятые в вашей инфраструктуре.

Заключение

Мы настроили Git в Termux с интеграцией Git LFS, добавили GPG‑подписи коммитов и разобрали практические хуки для контроля качества изменений: от политики подписи до предотвращения случайной “потери” больших файлов вне LFS. Такой подход улучшает воспроизводимость и снижает риски в распределённой разработке, сохраняя совместимость с настольными рабочими станциями и CI.

Если вы хотите внедрить этот workflow “под ключ” для вашего проекта (репозитории, шаблоны хуков, правила LFS, требования к подписи, настройка CI/проверок), обращайтесь в РыбинскЛАБ — поможем спроектировать и реализовать безопасную систему контроля версий под ваши процессы.