Что самое важное при использовании интерактивного rebase в Git?

Ответ

Самое важное правило: никогда не делайте интерактивный rebase для коммитов, которые уже были отправлены в общий репозиторий (push). Это перезаписывает историю и вызывает конфликты у всех, кто уже склонировал эти изменения.

Интерактивный rebase (git rebase -i) — это мощный инструмент для локальной очистки истории перед тем, как поделиться работой.

Основное применение и команды:

# Перебазировать последние 4 коммита текущей ветки
git rebase -i HEAD~4

В открывшемся редакторе вы можете:

  • pick — оставить коммит как есть.
  • reword — изменить сообщение коммита.
  • edit — остановиться для внесения изменений в сам коммит.
  • squash или fixup — объединить коммит с предыдущим (fixup отбрасывает его сообщение).
  • drop — удалить коммит.

Пример сценария (объединение коммитов):

# Исходная история: 4 коммита с мелкими правками
pick a1b2c3 Добавил новую функцию
pick d4e5f6 Исправил опечатку в комментарии
pick g6h7i8 Добавил недостающую проверку
pick j8k9l0 Обновил документацию

# После редактирования (объединяем правки в один логический коммит):
pick a1b2c3 Добавил новую функцию
fixup d4e5f6 Исправил опечатку в комментарии
fixup g6h7i8 Добавил недостающую проверку
pick j8k9l0 Обновил документацию
# Результат: 2 коммита — один с функцией и правками, второй с документацией.

Практический совет: Я использую интерактивный rebase в своей feature-ветке перед созданием пул-реквеста, чтобы создать чистую, логичную историю, которую легко ревьюить и мержить.

Ответ 18+ 🔞

Давай я тебе на пальцах объясню, как не наебнуться с гитом так, чтобы потом вся команда тебя ненавидела. Главное правило, которое надо выжечь себе на лбу: никогда не делай интерактивный ребейз для коммитов, которые уже улетели в общий репозиторий (push). Это, блядь, переписывает историю, и у всех, кто уже скачал твои изменения, начнётся пиздец и бардак. Представь, ты всем подменил учебники истории в библиотеке — доверия ебать ноль после такого.

Интерактивный ребейз (git rebase -i) — это твой личный хирургический инструмент для локальной чистки истории, пока ты не выложил свой треш на всеобщее обозрение.

Как этим пользоваться, не облажавшись:

# Переписать историю последних 4 коммитов в текущей ветке
git rebase -i HEAD~4

Тут откроется редактор, и ты сможешь с ними делать что угодно, как с пластилином:

  • pick — оставить коммит в покое.
  • reword — поменять сообщение коммита (часто надо, когда написал хуйню).
  • edit — остановиться, чтобы что-то допилить или исправить прямо в этом коммите.
  • squash или fixup — схлопнуть коммит с предыдущим. Разница в том, что fixup выкидывает его сообщение нахуй, а squash оставит тебе их все для редактирования.
  • drop — просто удалить коммит, будто его и не было.

Реальный пример из жизни, когда всё пошло по пизде: Допустим, ты накодил фичу и накоммитил туда всякой ерунды.

# Было так: 4 коммита, из которых три — мусорные правки
pick a1b2c3 Добавил новую функцию
pick d4e5f6 Исправил опечатку в комментарии
pick g6h7i8 Добавил недостающую проверку
pick j8k9l0 Обновил документацию

Ты смотришь на это и думаешь: «Ёпта, да это же один логический кусок работы, а не четыре!». Берёшь и переделываешь:

# Стало так: объединяем все мелкие правки в один нормальный коммит
pick a1b2c3 Добавил новую функцию
fixup d4e5f6 Исправил опечатку в комментарии
fixup g6h7i8 Добавил недостающую проверку
pick j8k9l0 Обновил документацию

Итог: Вместо четырёх кривых коммитов у тебя теперь два красивых и понятных: один — сама функция со всеми правками, второй — документация к ней. Чисто, аккуратно, и тому, кто будет это смотреть, не захочется тебе вилкой в глаз.

Мой совет, как для себя: Я всегда юзаю интерактивный ребейз в своей feature-ветке прямо перед тем, как создать пул-реквест. Вычищаю весь свой локальный треш, собираю работу в логичные блоки. Получается история, которую легко читать, ревьюить и без боли смержить. Главное — делай это ДО того, как запушил, и всё будет охуенно.