Основы Git: ветки, слияния и pull request

Git хранит снимки проекта во времени. Ветка — подвижный указатель на коммит. Слияние объединяет истории (часто после ревью). Pull request (merge request) — социальный слой: обсуждение diff, CI, затем интеграция.

Виджеты урока: git-graph показывает топологию — так видно, почему конфликты возникают на слиянии. Pipeline — путь изменения от редактора до общего remote. Code explorer разбирает команды. Таблица — merge vs rebase. Вкладки — синхронизация и откат.

Схема: feature-ветка и merge-коммит

Сначала смотрите на граф: main прошёл c1 → c2, ветка feature/login добавила c3 поверх c2. Слияние влило c3 в main как c4. Если бы двое правили одни строки после c2, Git остановился бы на конфликте — нужно собрать итоговый файл вручную.

Точка = коммит; дорожки = ветки. Клик по c4: два родителя (c3 и c2) — так Git хранит обе линии истории.
GIT GRAPH · 2 branches · 4 commits
mergemainfeature/login
Git graph
Click a commit to see details
main
feature/login
4 commits · 2 branches · click a commit to inspect
От рабочей копии до remote

Файлы в рабочей директории. `git add` кладёт снимок в индекс (staging). `git commit` фиксирует его в локальном репозитории. `git push` отправляет коммиты на remote (например origin).

Шаги pipeline: Правки — ещё не в истории. Индекс — что войдёт в следующий коммит (`git diff --cached`). Коммит — локальный DAG. Push публикует; до него CI и бэкапы «не видят» работу. PR — ревью и проверки до попадания в main.

Пройдите шаги: локально vs на сервере. Если CI упал после push — новые коммиты в той же ветке обновляют PR.
Правки
не закоммичено
git add
staging / index
git commit
локальный DAG
git push
origin
PR / ревью
CI + merge
▶
Разбор частых команд

Code explorer: строки идут в порядке ветка → статус → diff → индекс → коммит → push. В новых версиях Git для веток предпочтительны `git switch` / `git restore`.

Пояснения справа сопоставьте с pipeline выше.
bash
1
git checkout -b feature/login
▼
2
# правки файлов, затем:
▼
3
git status
▼
4
git diff
▼
5
git add -p
▼
6
git commit -m "feat: форма входа"
▼
7
git push -u origin feature/login
▼
Merge и rebase

Оба способа подтянуть main в feature. Merge добавляет merge-коммит (как c4). Rebase переписывает коммиты поверх main — линейная история, но меняются SHA. Не делайте rebase опубликованных коммитов, от которых ответвились другие.

Выбор стратегии в настройках PR или локально: merge честнее к графу, rebase аккуратнее для git log.
MergeRebase
Граф историиВидна развилка и пузырь merge — отражает параллельную работуЛиния: коммиты feature переносятся на вершину main
Совместная работаБезопасно при общих ветках — без переписывания историиОпасно, если коллеги уже стянули старые SHA
КонфликтыОбычно один раунд при слиянииМожет быть конфликт на каждый переносимый коммит
КогдаСтандарт «Create merge commit» на GitHub/GitLabgit pull --rebase; интерактивный rebase перед merge
Чеклист перед PR

Перед ревью

Меньшие PR сливаются быстрее. CI зелёный; напишите, что проверили руками.
В заголовке и теле PR — зачем изменение, не только diff.
Ссылка на задачу; отметьте рискованные места (auth, платежи, миграции).
Падающий CI — чините или объясняйте, не вешайте на ревьюеров.
Подтянуть main в feature
bash
git fetch origin
git checkout feature/login
git merge origin/main
# или: git rebase origin/main
Практика: тестовый репозиторий, два клона, два «разработчика», намеренный конфликт merge — лучший способ понять Git.