Git шпаргалка: в чем разница между fetch, pull и pull --rebase?

Казалось бы, все эти команды нужны для того, чтобы забрать изменения из удаленного репозитория. Но дьявол кроется в деталях (и в структуре вашей истории коммитов!).
1. git fetch
Вы скачиваете новые коммиты из удаленного репозитория (C и D), но они не сливаются с вашим кодом автоматически.
• Что происходит: Обновляется только указатель origin/main. Ваша локальная ветка main с вашими коммитами (X и Y) остается нетронутой.
• Когда использовать: Когда нужно просто посмотреть, что там нового написали коллеги, не ломая свою текущую работу.
2. git pull
Эта команда делает fetch, а затем сразу же автоматически пытается слить (merge) удаленные изменения с вашими локальными.
•. Что происходит: Создается новый специальный мерж-коммит (M), который соединяет ветку с изменениями коллег и вашу ветку. Ваши коммиты X и Y остаются в исходном виде.
•. Когда использовать: Самый частый сценарий, но будьте готовы к тому, что история коммитов превратится в «паутину» из-за обилия мерж-коммитов.
3. git pull --rebase
Комбинация fetch + rebase. Вместо создания мерж-коммита, Git берет ваши локальные коммиты и «переносит» их на самый верх свежих изменений из удаленного репозитория.
•. Что происходит: Старые коммиты X и Y стираются, а вместо них создаются новые X' и Y', которые аккуратно встают после коммитов C и D.
•. Когда использовать: Когда вы хотите, чтобы история вашего репозитория выглядела как одна красивая прямая линия, без лишнего мусора.
Краткий итог:
• Хотите просто проверить? git fetch
• Быстро обновиться (по классике)? git pull
• Нужна чистая, линейная история коммитов? git pull --rebase