Git для аналитика данных: за час с нуля до production

«Зачем мне Git, я же не программист» — самая дорогая мысль аналитика. На второй год работы у тебя будет 200 SQL-запросов в Notion, 50 Jupyter notebook'ов в Yandex.Disk, и 30 dashboard-моделей раскиданных по 5 источникам. Когда коллега спросит «откуда эта цифра», ты потратишь час на поиск.

Git решает это раз и навсегда. Этот гайд — за час разбираешься в Git до production-уровня. Без академической теории.

Зачем Git аналитику конкретно

Code review SQL/Python

Коллега смотрит твой запрос ДО того как ты его пушишь в дашборд. Находит баги. Учит тебя.

История изменений

«Когда мы поменяли формулу LTV?» → git log → 14 марта, коммит "fix: учитываем refunds в LTV". Известно кто, когда, зачем.

Откат

Поменял формулу retention, метрики поползли вниз → git revert → возвращаешь предыдущую версию за 5 секунд.

Параллельная работа

Ты делаешь A/B-анализ, коллега — ETL. Никто никому не мешает, в конце сливаете изменения.

dbt / Airflow требуют Git

Современный data stack без Git не работает. Хочешь dbt — учи Git.

Reality check

В 80% компаний с грейдом Middle+ Git — обязательное требование. На собеседовании вопрос «как commit'ишь?» = автоматический red flag если не ответишь.

Установка (5 минут)

Mac:

# Проверь — может уже есть
git --version

# Если нет
brew install git

Windows:

Скачай с git-scm.com → установщик.

Linux:

sudo apt install git

Настройка (один раз):

git config --global user.name "Твоё Имя"
git config --global user.email "tvoj@email.ru"

12 команд которые покрывают 95% работы

`git clone` — скачать чужой репозиторий

git clone https://github.com/company/analytics-repo.git
cd analytics-repo

`git status` — что у меня изменено?

git status
# Покажет: какие файлы новые, какие изменены

`git diff` — что именно изменилось?

git diff sql/retention.sql
# Покажет diff по файлу

`git add` — добавить в "корзину" коммита

git add sql/retention.sql       # один файл
git add sql/                    # вся папка
git add .                       # ВСЁ изменённое (опасно — может зацепить мусор)

`git commit` — зафиксировать снимок

git commit -m "fix: учитываем refunds в retention расчёте"

Хороший commit message: глагол + что сделал + почему.

`git push` — отправить на сервер

git push origin main

`git pull` — забрать чужие изменения

git pull origin main
# Скачает + смержит изменения коллег

`git branch` + `git checkout -b` — отдельная ветка для своей задачи

git checkout -b feature/new-funnel-dashboard
# Создал ветку, работай, не мешая main

`git log` — история коммитов

git log --oneline --graph -20
# Последние 20 коммитов в красивом виде

`git stash` — временно отложить незакоммиченное

git stash             # сохранил текущие правки в "закладку"
git pull origin main  # потянул чужие
git stash pop         # вернул свои правки сверху

`git revert` — откатить коммит

git revert HEAD       # отменяем последний коммит (создаёт новый "обратный")
git revert abc1234    # отменяем конкретный коммит по hash

`git merge` — слить ветки

git checkout main
git merge feature/new-funnel-dashboard

Всё. Этих 12 команд хватит на 95% работы аналитика.

Workflow для команды (Pull Request flow)

Шаг 1: новая фича

git checkout main
git pull origin main
git checkout -b feature/q1-revenue-dashboard

Шаг 2: работаешь, периодически коммитишь

# Делаешь правки
git add sql/q1_revenue.sql
git commit -m "feat: add Q1 revenue aggregation"

# Ещё правки
git add dashboards/q1_revenue.json
git commit -m "feat: add Q1 dashboard config"

Шаг 3: пушишь и открываешь Pull Request на GitHub

git push origin feature/q1-revenue-dashboard

# Идёшь на github.com → создаёшь Pull Request
# Колеги ревьюят, ты правишь

Шаг 4: после approve — merge в main

В UI GitHub нажимаешь «Merge pull request» → ветка попадает в main → автоматический деплой через CI/CD.

Conflict resolution (страшно — но просто)

Что-то пошло не так:

git pull origin main
# Auto-merging sql/retention.sql
# CONFLICT (content): Merge conflict in sql/retention.sql

Открой файл — увидишь:

SELECT user_id, COUNT(*) AS sessions
FROM events
<<<<<<< HEAD
WHERE event_type = 'pageview'
=======
WHERE event_type IN ('pageview', 'click')
>>>>>>> main
GROUP BY user_id;

Между <<< и === — твоя версия. Между === и >>> — чужая. Удали маркеры, оставь то что нужно (или объедини оба):

SELECT user_id, COUNT(*) AS sessions
FROM events
WHERE event_type IN ('pageview', 'click')
GROUP BY user_id;

Сохрани, потом:

git add sql/retention.sql
git commit -m "merge: объединить условие event_type"

Совет: если конфликт сложный — пиши коллеге чьи правки. Лучше 5 минут discusss чем гадать.

.gitignore — что НЕ коммитить

В аналитике важно НЕ коммитить:

Credentials (.env, config.yaml с паролями)
Большие данные (CSV / JSON > 10MB)
Jupyter notebook output (грязные cells)
Личные настройки IDE (.vscode/, .idea/)

Создай файл .gitignore в корне:

.env
.env.local
__pycache__/
*.pyc
.ipynb_checkpoints/
data/raw/*.csv
data/raw/*.json
.vscode/
.DS_Store

Этот файл коммитится (git add .gitignore), но всё что в нём указано — игнорируется git'ом.

Структура проекта аналитика

analytics/
├── .gitignore
├── README.md
├── sql/
│   ├── staging/
│   │   ├── stg_users.sql
│   │   └── stg_orders.sql
│   ├── marts/
│   │   ├── monthly_revenue.sql
│   │   └── retention_cohort.sql
│   └── adhoc/
│       └── 2026-04-25_marketing_question.sql
├── notebooks/
│   ├── ab_tests/
│   └── exploration/
├── airflow_dags/
└── docs/
    └── metric_definitions.md

Папка adhoc/ — для разовых запросов с датой и темой. Через год сможешь найти «что я делал в апреле».

Boilerplate для первого репозитория

# 1. Создай папку
mkdir my-analytics-repo
cd my-analytics-repo

# 2. Init git
git init

# 3. Создай README
echo "# Analytics workspace" > README.md

# 4. Создай .gitignore
cat > .gitignore << 'EOF'
.env
__pycache__/
.ipynb_checkpoints/
data/raw/
.DS_Store
EOF

# 5. Первый коммит
git add .
git commit -m "initial commit"

# 6. Создай repo на GitHub.com → скопируй URL
git remote add origin https://github.com/yourname/my-analytics-repo.git
git push -u origin main

Теперь твоя работа версионируется.

Anti-patterns которые увидят на code review

❌ Огромный коммит "fixed everything"

Не коммить 50 файлов с месседжем "fixes". Один коммит = одна логическая правка.

❌ Push --force на main

Стирает чужие коммиты. Никогда не делай --force на main без чёткого согласования с командой.

❌ Коммит credentials

DB_PASSWORD = "supersecret123"  # коммит этого = бан в команде

Используй os.environ + .env файл (в .gitignore).

❌ Коммит 200MB CSV

GitHub ругается, репозиторий раздувается. Большие данные — в S3 / Yandex Object Storage.

Связанные материалы

SQL-тренажёр — материал для коммитов в твой репозиторий
dbt для аналитика — dbt = SQL под git
Junior, Middle, Senior грейды — Git у Middle+ обязателен
Топ-50 вопросов на собеседовании — про Git тоже спрашивают

Создай свой первый репозиторий за 10 минут (boilerplate выше). Коммить туда любую SQL-задачу из тренажёра — за неделю репозиторий станет твоим портфолио для показа на собесах.