Git: от clone до pull request

Минимальный набор, чтобы работать в команде и не терять код.

Git хранит историю изменений проекта и даёт нескольким людям работать над одним кодом, не затирая друг друга. Для инженера данных это не опция: DAG-и Airflow, SQL-модели, скрипты загрузки, всё лежит в git, и через него же уезжает на прод.

Три места, где живут файлы

Самое важное, что нужно понять в git, это три состояния файла:

Рабочая папка — обычные файлы на диске, которые вы правите.
Индекс (staging) — список того, что попадёт в следующий коммит. Туда файлы кладёт git add.
История коммитов — снимки, которые сохранил git commit.

Команда git status показывает, где что находится, и подсказывает следующий шаг. Запускайте её часто, это бесплатно.

Первый репозиторий

git init                       # превратить папку в репозиторий
git status                     # что изменилось
git add sql/orders.sql         # положить файл в индекс
git add .                      # все файлы сразу
git commit -m "Загрузка заказов"   # сохранить снимок
git log --oneline              # история коротко

Коммит это сообщение плюс снимок. Сообщение пишут так, чтобы через полгода было понятно, что и зачем: «Ограничение выборки заказов 100 строками для тестов» лучше, чем «fix».

Посмотреть, что изменилось

git diff                   # изменения в рабочей папке, ещё не в индексе
git diff --staged          # то, что уже в индексе и уйдёт в коммит
git restore sql/orders.sql # отменить правки файла, вернуть как в последнем коммите
git restore --staged sql/orders.sql   # убрать из индекса, файл не трогать

Ветки

Ветка это отдельная линия истории. Правило команды простое: main всегда рабочий, а каждая задача делается в своей ветке и вливается в main, когда готова и проверена.

git branch                    # список веток, звёздочка у текущей
git checkout -b feature/limit # создать ветку и перейти в неё
git checkout main             # вернуться
git merge feature/limit       # влить ветку в текущую
git branch -d feature/limit   # удалить влитую ветку

Если в двух ветках изменили одну и ту же строку, при слиянии будет конфликт. Git пометит место в файле маркерами <<<<<<<, =======, >>>>>>>. Вы оставляете правильный вариант, убираете маркеры, делаете git add и git commit. Страшно только первые два раза.

Удалённый репозиторий и pull request

GitHub, GitLab или Bitbucket хранят общую копию. Локальный репозиторий с ней синхронизируется:

git clone git@github.com:team/etl-shop.git   # скачать проект в первый раз
git remote -v                                # куда смотрит origin
git pull                                     # забрать чужие изменения
git push -u origin feature/limit             # отправить свою ветку

Pull request (в GitLab merge request) это просьба влить вашу ветку в main с обсуждением и ревью. Обычный цикл задачи: git pull в main, новая ветка, коммиты, git push, pull request, ревью, merge, удалить ветку. Через месяц это делается на автомате.

Практика

Перед вами проект без истории. Доведите его до состояния «отправлен в удалённый репозиторий».

git в песочницезадания 0 / 7

Введите команду. Подсказка: help покажет, что умеет этот терминал.

de@deshka:~/etl-shop$

ЗАДАНИЯ

1. Инициализируйте репозиторий в папке etl-shop
2. Допишите .env в .gitignore, чтобы пароль не попал в репозиторий
3. Сделайте первый коммит со всеми файлами, кроме .env
4. Создайте ветку feature/limit и переключитесь на неё
5. В ветке feature/limit добавьте в sql/orders.sql строку 'limit 100;' и закоммитьте
6. Вернитесь на main и влейте feature/limit
7. Подключите удалённый репозиторий origin и отправьте main

решённые задания сохранятся в прогресс после входа

Что запомнить

Рабочая папка → git add → индекс → git commit → история. git status показывает, где вы.
Одна задача = одна ветка. main не трогают напрямую.
.gitignore до первого коммита, а не после утечки.
git pull перед началом работы, git push и pull request в конце.