Ветки и Pull Request

Один в репозитории вы работаете быстро. В команде нужны правила. Основное правило такое: в main код попадает только после ревью. main — это продакшен. Его нельзя ломать.

Ветки

Ветка — отдельная линия изменений. Вы делаете её от main, правите код, а main остаётся нетронутым.

main:      A ── B ── C ───────────── G   ← merge
                      \             /
fix-revenue:           D ── E ── F

git switch -c fix-revenue      # создать ветку и перейти в неё
git branch                     # список веток
git switch main                # вернуться в main

Имя ветки — коротко, что делаете: fix-revenue, add-refunds. В компаниях часто добавляют номер задачи: DE-123-add-refunds.

Рабочий цикл в команде

1. git switch -c add-refunds     ← ветка от main
2. правим код, git add, git commit
3. git push -u origin add-refunds ← отправляем ветку на GitHub/GitLab
4. открываем Pull Request (Merge Request)
5. коллеги смотрят код, пишут замечания
6. правим, делаем новые коммиты, git push
7. CI зелёный и есть approve → merge в main
8. удаляем ветку

Подключите удалённый репозиторий

На GitHub нажмите New repository. Назовите его sql-reports. Не добавляйте README: репозиторий должен быть пустым.
Подключите его к локальному репозиторию:

git remote add origin git@github.com:YOUR_NAME/sql-reports.git
git push -u origin main

origin — имя удалённого репозитория по умолчанию.
-u запоминает связь, дальше хватит git push.

Обновите страницу на GitHub: там ваши файлы и история коммитов.

Чужой репозиторий копируют командой git clone:

git clone git@github.com:company/analytics.git

Pull Request и Merge Request

После git push ветки GitHub показывает кнопку Compare & pull request. На GitLab кнопка называется Create merge request.

Это одно и то же. Вы просите команду: «Посмотрите мои изменения и добавьте их в main».

	GitHub	GitLab
Название	Pull Request (PR)	Merge Request (MR)
Автоматические проверки	GitHub Actions (`.github/workflows/*.yml`)	GitLab CI/CD (`.gitlab-ci.yml`)
Защита `main`	Branch protection rules / Rulesets	Protected branches
Одобрение	Approve в Review	Approve в Merge Request
Где работает	github.com, GitHub Enterprise	gitlab.com, self-hosted GitLab

Идея одинаковая. Названия и кнопки разные. Выучите один раз. Второй освоите за час.

Хороший Pull Request

Маленький. Одна задача. Читать 20 строк легко. Читать 2000 — никто не будет внимательно.
С понятным названием и описанием. Что изменилось и зачем. Как проверить.
С зелёным CI. Не просите ревью, пока проверки красные.

Ревью

Ревьюер смотрит diff и пишет замечания к конкретным строкам. Затем выбирает одно из трёх:

Approve — всё хорошо.
Request changes — нужно исправить.
Comment — вопрос или совет.

Что искать в SQL-ревью:

Совпадает ли гранулярность (grain) с ожидаемой?
Нет ли дублей после JOIN?
Обрабатываются ли NULL?
Нет ли секретов в коде?

Ревью — не проверка человека. Это способ найти ошибку до продакшена и поделиться знанием.

merge — объединить

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

git switch main
git pull
git branch -d add-refunds      # удалить локальную ветку

Кнопки merge на платформах бывают в трёх вариантах: merge commit, squash и rebase. На старте берите Squash and merge. Все коммиты ветки склеятся в один чистый коммит в main.

Конфликты

Конфликт возникает, когда два человека поменяли одни и те же строки. Git не знает, чья версия правильная, и просит решить вас.

В файле появляются маркеры:

<<<<<<< HEAD
where status = 'completed'
=======
where status in ('completed', 'shipped')
>>>>>>> add-refunds

Что делать:

Откройте файл. Оставьте нужный вариант. Удалите маркеры <<<<<<<, =======, >>>>>>>.
git add <файл>
git commit

Конфликтов меньше, если ветки короткие и вы чаще делаете git pull.

Практика

Полную практику на настоящих сайтах вы пройдёте в следующих уроках: GitHub и GitLab. Там вы создадите бесплатный репозиторий, заведёте Issue, откроете Pull Request и Merge Request.

Здесь потренируйте конфликт локально. Для этого хватит репозитория sql-reports из прошлого урока.

Задание. Конфликт

Создайте ветку a от main. Поменяйте в models/revenue.sql строку where на where status = 'completed' and amount > 0. Сделайте коммит.
Вернитесь в main. Поменяйте ту же строку на where status in ('completed', 'shipped'). Сделайте коммит.
В main выполните git merge a.

Проверка: Git пишет CONFLICT. Решите конфликт: оставьте условие status in ('completed', 'shipped') and amount > 0. Завершите merge.

Решение

git switch -c a
# правим файл
git commit -am "Filter amount > 0"
git switch main
# правим ту же строку
git commit -am "Include shipped orders"
git merge a
# открываем файл, убираем маркеры, оставляем нужное условие
git add models/revenue.sql
git commit -m "Merge branch a"