15 апреля 2026 г.

Как устроить GitHub для аналитика

Зачем аналитику GitHub

Одиночный аналитик может выжить без Git. В команде 2+ человек без него — хаос. SQL-скрипт у Пети, дашборд у Саши, непонятно кто что меняет.

Git даёт версионирование, review, возможность откатиться. GitHub (или GitLab, Bitbucket) — интерфейс для совместной работы.

Для аналитика не нужно идеально знать Git. Базовые commands, ветвление, PR — достаточно для 95% ежедневной работы.

Что хранить в репозитории

Типичный аналитический репозиторий содержит:

SQL-скрипты — все ваши SQL, особенно reusable queries.

Jupyter notebooks — для анализов. С осторожностью (см. ниже).

dbt-проект — модели, тесты, документация.

Python-скрипты — автоматизация, ETL-утилиты.

Airflow DAGs — если вы пишете пайплайны.

Документация — README, соглашения, процессы.

Не храните: credentials, raw данные (большие файлы), временные файлы, output каких-то скриптов.

Структура проекта

Один из популярных вариантов:

analytics-repo/
├── README.md
├── .gitignore
├── sql/
│   ├── reusable/
│   │   ├── daily_gmv.sql
│   │   └── cohort_retention.sql
│   └── adhoc/
│       └── 2026-04-15-churn-investigation.sql
├── notebooks/
│   ├── exploratory/
│   │   └── user_behavior_eda.ipynb
│   └── reports/
│       └── 2026-q1-review.ipynb
├── dbt_project/
│   ├── models/
│   ├── tests/
│   └── dbt_project.yml
├── scripts/
│   ├── weekly_report.py
│   └── metrics_snapshot.py
├── airflow/
│   └── dags/
│       └── daily_etl.py
└── docs/
    ├── metric_definitions.md
    └── runbooks/

Логика: reusable код отдельно от ad-hoc, notebook-ы отдельно от production scripts.

Коммиты: как и что

Хороший коммит — это маленькое логическое изменение с понятным описанием.

Плохо:

commit: stuff
commit: fix
commit: final version

Хорошо:

commit: add daily_gmv.sql with comments
commit: fix typo in cohort_retention query
commit: add weekly_report Python script

Правила:

Subject — короткое (до 50 символов) описание что сделали.
Тип обычно первый: feat:, fix:, docs:, refactor:.
Если нужно больше — пустая строка и подробное описание.

Branching

Типичная схема для аналитической команды:

main — production-ready код. Только проверенные, working изменения.

feature/* — для новых фич. feature/add-retention-dashboard.

fix/* — для исправлений. fix/revenue-query-bug.

Workflow:

Создали ветку от main.
Работаете, коммитите.
Открываете Pull Request в main.
Code review от коллеги.
Merge.

Для маленьких личных изменений можно работать прямо в main. Для serious — всегда через PR.

Pull Requests

PR — не просто «пожалуйста замерджи». Это интерактивный review.

Хороший PR:

Описание в самом PR: что, зачем, как тестировали.
Маленький (не 50 файлов).
Одно логическое изменение.
Ссылка на Jira / Linear ticket.

Пример описания PR:



## Что делаем

Добавляем dbt-модель mart_daily_revenue для ежедневного отчёта.


Больше таких примеров с разборами — в [Telegram-тренажёре](https://t.me/kariernik_bot/app?startapp=web_blog_kak-ustroit-github-dlya-analitika_mid1). Короткие сессии, прогресс по темам, объяснения после каждого ответа.

## Зачем

CMO просила автоматический daily revenue breakdown по regions.

## Как тестировали

- dbt test passed
- Сравнил результаты с текущим Excel-отчётом за последнюю неделю
- Цифры совпадают

## TODO / Risks

- Нужна настройка Airflow-запуска
- В первой версии без regions breakdown, добавлю в follow-up

Code review

Reviewer смотрит и оставляет комментарии. Типы:

Blocker — обязательно исправить.
Suggestion — подумать, но можно и не менять.
Nit — мелочи (пробелы, именование).
Question — уточнение.

Автор отвечает на каждый комментарий. После resolve всех blockers — merge.

.gitignore

Критически важно для аналитики. Что НЕ должно попадать в git:

# credentials
.env
*.pem
secrets.yaml

# data files
*.csv
*.parquet
*.pkl
data/raw/

# Jupyter checkpoints
.ipynb_checkpoints/

# Python
__pycache__/
*.pyc
.venv/

# dbt
target/
logs/

# IDE
.vscode/
.idea/
*.swp

# System
.DS_Store

Если case sensitive credentials попали в git — беда. Пароль в истории даже после removal.

README как must-have

Каждый репозиторий — с README. Минимум:

# Analytics Team Repository

## Структура

- `sql/` — SQL-скрипты
- `dbt_project/` — dbt-модели
- `scripts/` — Python-скрипты
- `notebooks/` — Jupyter



## Setup

1. Клонировать
2. Создать venv: `python -m venv .venv`
3. Установить: `pip install -r requirements.txt`
4. Скопировать `.env.example` в `.env`, заполнить


Если готовишься к собесу — [бот @kariernik_bot](https://t.me/kariernik_bot/app?startapp=web_blog_kak-ustroit-github-dlya-analitika_mid2) закрывает 80% технических вопросов. SQL, Python, A/B, продуктовые метрики — всё в одном месте.

## Запуск отчётов

- Weekly: `python scripts/weekly_report.py`
- Daily: автоматически через Airflow

## Контакты

- Tagir — main analytics
- Slack: #analytics-team

README экономит часы onboarding новичков.

Notebooks в git: проблема

Jupyter .ipynb — это JSON. При изменении вывод ячеек тоже изменяется — git diff становится огромным и нечитаемым.

Решения:

nbstripout. Автоматически убирает outputs перед коммитом:

pip install nbstripout
nbstripout --install

Jupytext. Сохраняет notebook как .py, читаемо для git. Менее популярно, но мощно.

Конвенция: перед коммитом "Kernel → Restart & Clear Output".

Без одной из этих практик notebooks в git — пожалеете.

Секреты

Никогда не коммитить:

Пароли, API keys, tokens.
Connection strings с credentials.
Private keys.

Используйте:

Environment variables.
.env файлы (в .gitignore).
Secret managers (AWS Secrets Manager, HashiCorp Vault).

Если случайно committed — не просто удалите. История сохранилась. Rotate credentials немедленно.

Commit hooks

Pre-commit hooks автоматически проверяют код перед commit. Популярные tools:

pre-commit — manager для hooks.
sqlfluff — linter для SQL.
black — formatter Python.
gitleaks — детекция credentials.

Пример .pre-commit-config.yaml:

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
  - repo: https://github.com/sqlfluff/sqlfluff
    rev: 3.0.0
    hooks:
      - id: sqlfluff-lint

Автоматизация защищает от многих ошибок.

FAQ

GitHub или GitLab?

Функционально похожи. GitLab имеет self-hosted edition, GitHub — популярнее.

Сколько branches нужно?

Одна main + feature branches для каждой задачи. Больше не нужно.

Notebook в git — зло?

Без nbstripout или jupytext — да. С ними — ок.

Как часто коммитить?

Минимум раз в день. Лучше — после каждого логического изменения.

Тренироваться в Telegram