Коротко — принципиальная разница в том, что:
- git fetch скачивает изменения из удалённого репозитория и обновляет только удалённо-отслеживаемые ветки (например origin/main). Он не трогает вашу текущую ветку и рабочие файлы.
- git pull делает fetch, а затем автоматически пытается объединить эти изменения в вашу текущую ветку (по умолчанию merge, можно настроить rebase).
Почему это важно и когда что использовать
1) Когда использовать git fetch
- Вы хотите сначала посмотреть, что изменилось на удалённом репозитории, прежде чем вносить изменения в свою рабочую копию.
- Нужна безопасная команда (не меняет рабочие файлы): fetch никогда не создаёт внезапных конфликтов в рабочем дереве.
- Перед принятием решения о слиянии/ребейзе: fetch + просмотр diff/log даёт возможность понять последствия и при необходимости подготовиться.
- Для CI/скриптов, анализа, обновления удалённых трекеров (например, чтобы увидеть новые ветки) без вмешательства в локальную ветку.
- Когда вам нужно удалить/синхронизировать удалённые ветки: git fetch --prune.
Типичный пример:
- git fetch origin
- git log --oneline HEAD..origin/main (что появилось на сервере)
- git diff --name-status HEAD..origin/main
- Если всё ок: git merge origin/main или git rebase origin/main
2) Когда удобен git pull
- Вы уверены, что хотите сразу применить изменения в текущей ветке (например, вы на main и просто хотите обновиться).
- Быстрое обновление без промежуточной проверки — удобно в простых рабочих процессах.
- Если удалённая ветка может быть просто «перемотана» вперёд (fast-forward), pull часто безопасен.
Рекомендации при использовании pull:
- Предпочтительно использовать git pull --ff-only, если вы хотите избежать автоматических merge-коммитов. Эта опция отменит операцию, если нужен не fast-forward.
- Многие предпочитают git pull --rebase или установить pull.rebase=true — это делает историю чище (не создаёт лишних merge-коммитов), но требует внимания: rebase переписывает локальные коммиты.
Как конфликты влияют на выбор
- git pull может сразу запустить merge/rebase и привести к конфликтам в рабочей копии. Если вы не готовы их решать немедленно — это неудобно.
- git fetch безопасен: вы посмотрите, где конфликт потенциально будет (git diff/ log), и сможете подготовиться (сделать stash, перезаписать, договориться с командой), а потом выполнить merge/rebase вручную.
Практические советы
- Для основной ветки (main/master) часто достаточно: git pull --ff-only (или периодически fetch+inspect).
- Для работы на feature-ветке с локальными коммитами: git fetch, проверить изменения, затем git rebase origin/main (или merge) — так контролируете процесс и меньше «сюрпризов».
- Если не уверены — всегда fetch сначала.
- Для удаления уже удалённых веток: git fetch --prune.
Краткое резюме
- git fetch = «скачать и обновить remote-tracking refs» (без изменения вашей ветки).
- git pull = fetch + автоматически применить изменения к текущей ветке (merge или rebase) — быстрее, но менее контролируемо.
- Используйте fetch для проверки/контроля, pull — когда хотите быстрый апдейт и уверены в результате (или настроили безопасный режим, например --ff-only или --rebase).