Что делает команда `git rebase` и когда её следует использовать?

Ответ

git rebase перемещает (перебазирует) всю историю коммитов одной ветки на вершину другой ветки, создавая линейную историю.

Основное использование:

git checkout feature-branch
git rebase main
# Теперь коммиты из feature-branch применяются поверх актуального main

Зачем это нужно?

  • Чистая история: Избегает лишних merge-коммитов, сохраняя историю линейной и легко читаемой.
  • Интеграция изменений: Позволяет проверить, что ваша ветка корректно работает с последними изменениями в базовой ветке (например, main или develop).

Ключевые особенности и риски:

  • Перезапись истории: Изменяет хэши коммитов. Нельзя использовать для коммитов, уже отправленных в общий репозиторий, если с ними работали другие разработчики.
  • Интерактивный режим (-i): Позволяет редактировать, объединять (squash), удалять или менять порядок коммитов перед применением.
  • Разрешение конфликтов: Конфликты могут возникать для каждого перебазируемого коммита, что требует их последовательного разрешения.

Сравнение с git merge:

  • rebase: «Переписывает» историю, перемещая ваши коммиты. Используется для подготовки ветки к слиянию.
  • merge: Сохраняет полную историю, создавая новый коммит слияния. Безопаснее для публичных веток.

Ответ 18+ 🔞

А, ну вот, опять про этот ваш git rebase! Слушай, представь себе такую хуйню. У тебя есть ветка, как будто ты отъехал от главной дороги в свой личный посёлок «Фича-Двор» и там накодил кучу домиков-коммитов. А пока ты хуярил, главная дорога main уехала вперёд, и теперь твой съезд в посёлок торчит из середины поля, а не от новой развязки.

Так вот, git rebase — это не слияние, нет, блядь. Это волшебный, ёпта, кран, который поднимает ВЕСЬ твой посёлок «Фича-Двор» — ВМЕСТЕ С ФУНДАМЕНТОМ — и аккуратно ставит его на самый свежий конец главной дороги. И вуаля! Теперь твоя история выглядит так, будто ты изначально начал строить от самой новой точки. Линейно, чисто, красиво. Никаких лишних merge-коммитов, которые как будто кто-то посреди дороги хуй воткнул со словами «тут было слияние».

Как это делается, если ты не идиот:

git checkout feature-branch  # Перешёл в свой посёлок
git rebase main             # И сказал: «Эй, кран, подними это всё на новую точку main!»

Зачем это, спрашивается, нужно?

  • История без пиздеца: Чтобы когда потом кто-то смотрел git log, у него глаза не вытекали от этих ебучих зигзагов слияний. Всё — одна прямая линия, коммит за коммитом.
  • Проверить, не сломалось ли: Ты свои изменения «прикладываешь» к самому свежему коду. Если конфликты есть — узнаешь сразу, а не в момент, когда уже пытаешься смержиться и у тебя всё горит.

Но тут, блядь, подводные ебучки:

  • Историю переписывает нахуй: Каждый твой коммит после переезда получает новый ID (хеш). Это как поменять паспорта всем жителям посёлка. НИКОГДА, СУКА, НИКОГДА не делай этого с коммитами, которые уже отправил в общий репозиторий! Коллеги, которые с ними работали, просто охуеют и захотят тебя убить.
  • Режим «хитрожопый» (-i): git rebase -i — это когда ты можешь перед переездом сказать: «А вот эти два домика-коммита склеиваем в один особняк (squash), а этот сарай вообще сносим (drop), и порядок поменяем». Мощнейшая штука, но страшная.
  • Конфликты — твоя проблема: Кран будет ставить твои коммиты по одному. И на каждом шаге может сказать: «А тут, мудила, на новой земле уже цветочки посажены, а у тебя в коммите асфальт. Решай». И так на каждом коммите. Веселье.

Чем отличается от git merge, спросишь?

  • rebase: «Я так задумал изначально». Переписывает историю, делает её аккуратной. Как будто так и было.
  • merge: «Было вот так, а потом мы соединили». Создаёт отдельный коммит-свидетель, что было слияние. История честная, но ветвистая. Для публичных веток — безопаснее и правильнее.

Короче, rebase — это инструмент для чистюль и перфекционистов, которые любят, чтобы в их огороде было гладко. Но если наступить на грабли, можно получить этими самыми граблями по ебалу. Пользуйся с умом, и да пребудет с тобой git reflog, если всё пойдёт по пизде.