В чем разница git pull и git fetch

Что проверяют

Понимаете ли вы, что происходит с локальными ветками при синхронизации с удалённым репозиторием, и умеете ли обновляться без сюрпризов. Следом обычно спрашивают, что делать, если pull закончился конфликтом, и чем merge отличается от rebase.

Как отвечать

Начните с того, что меняет каждая команда:

• git fetch: скачивает новые коммиты и обновляет ветки удалённого отслеживания вроде origin/main. Текущая ветка, индекс и рабочие файлы не меняются, поэтому команда безопасна в любой момент;
• git pull: это fetch плюс интеграция в текущую ветку. Классически интеграция делается слиянием, с флагом --rebase или настройкой pull.rebase=true ваши локальные коммиты переносятся поверх полученных. Свежие версии Git при разошедшихся ветках и не заданной настройке останавливаются и просят выбрать стратегию;
• pull.ff=only: pull проходит только перемоткой вперёд, а при расхождении веток останавливается и не создаёт лишний merge-коммит.

Покажите рабочий сценарий: git fetch, затем git log HEAD..origin/main или git diff, чтобы увидеть чужие изменения, и только потом merge или rebase. В .NET-проекте это особенно полезно, когда кто-то поменял .csproj, Directory.Packages.props или добавил миграцию EF Core: такие изменения лучше увидеть до слияния, чем разбираться с упавшей сборкой после.

Упомяните инструменты. В Visual Studio есть отдельные кнопки Fetch, Pull и Sync (Sync делает pull, затем push), в Rider при обновлении проекта выбирается merge или rebase. Под капотом это те же команды.

Где спотыкаются

Говорят, что fetch «скачивает изменения в мою ветку». Он обновляет только origin/*, локальная main остаётся на месте, пока вы её не сдвинете.

Не могут объяснить, как выйти из неудачного pull с конфликтом. Ответ: git merge --abort или git rebase --abort, в зависимости от стратегии.

Считают, что pull всегда создаёт merge-коммит. При перемотке вперёд его нет, он появляется только тогда, когда у вас и на сервере есть разные новые коммиты.