BookFlow - книги программирование

🔄 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 ♻️ Сделай репост, чтобы помочь другим. 📲 Мы в MAX 👉 @Bookflow