Ответ
Git rebase — это команда для перемещения или объединения последовательности коммитов одной ветки на вершину другой ветки. Она перезаписывает историю коммитов, создавая линейную последовательность, как если бы работа велась поверх самой актуальной базовой ветки.
Основное использование:
# Находясь в feature-ветке, перебазировать её на main
git checkout feature-branch
git rebase mainЭта команда:
- Временно сохраняет коммиты из
feature-branch. - Сбрасывает
feature-branchна тот же коммит, что иmain. - Последовательно применяет сохраненные коммиты поверх
main.
Плюсы:
- Чистая история: Убирает лишние merge-коммиты, история становится линейной и легко читаемой.
- Упрощение: Облегчает поиск по логам и бисекцию (git bisect).
Минусы и риски:
- Перезапись истории: Изменяет хэши коммитов. Опасно для веток, уже отправленных в общий репозиторий, так как сломает историю у других разработчиков.
- Конфликты: Может потребовать разрешения конфликтов для каждого перебазируемого коммита.
Правило: Используйте rebase для локальной очистки истории перед слиянием через merge. Для публичных веток используйте merge.
Ответ 18+ 🔞
Давай разберём эту штуку, которая у всех новичков вызывает священный ужас, а опытные её обожают — git rebase. Представь, что история коммитов — это не ветвящееся дерево, а ровная дорога, по которой ты идешь. Rebase — это волшебный инструмент, который позволяет эту дорогу переложить, выпрямить и пристыковать к самому свежему участку, как будто ты с самого начала шёл по нему.
Как это работает, если на пальцах:
Допустим, ты работал в своей ветке feature-branch, пока в main накапливались обновления. Твоя история сейчас похожа на развилку. Rebase делает следующее:
- "Снимает" все твои коммиты с ветки, как будто откручивает их.
- Ставит твою ветку на самый свежий кончик
main. - Прикручивает твои коммиты обратно, но уже поверх новой основы, один за другим.
Вот так это выглядит в терминале, без всякой магии:
# Переходишь в свою ветку-песочницу
git checkout feature-branch
# И говоришь: "Хочу переложить мою дорогу на самый свежий асфальт main"
git rebase mainПочему это офигенно:
- История — чистый алмаз. Никаких лишних merge-коммитов типа "Merge branch 'main' into feature-branch", от которых глаза слезятся. Одна линейная, красивая цепочка событий. Искать что-то в логах или искать баг через
git bisect— одно удовольствие, ебать мои старые костыли.
Но тут, дружок, подвох и он пиздец какой серьёзный:
- История переписывается. Каждый твой перебазированный коммит получает новый уникальный хэш. Это как поменять паспорт у всех людей в твоей семье. Если ты уже отправил (
push) свою ветку в общий репозиторий, а потом её переписал (rebase), то у всех, кто с ней работал, начнётся ебаный апокалипсис. Их история разойдётся с твоей, и при следующемpullони увидят овердохуища конфликтов. Золотое правило:rebase— только для локальных, ещё не опубликованных веток. Для публичных — используй обычныйmerge, и всем будет спокойно. - Конфликты на каждом шагу. Если изменения в
mainи в твоей ветке пересекаются,rebaseбудет останавливаться на каждом твоём коммите и требовать разрешить конфликт. Это может быть утомительно, но зато история остаётся чистой.
Итоговая стратегия, чтобы не прослыть пидарасом шерстяным в команде:
- Работаешь локально в своей ветке — делай
rebaseнаmainхоть каждый день, чтобы быть в актуальном состоянии. - Закончил фичу, пора сливать? Сделай финальный
rebaseна свежийmain, чтобы твои коммиты легли красиво. - Перед тем как пушить в общую ветку, убедись, что ты там единственный автор. Если не уверен — лучше сделай обычный
merge. А потом уже пушишь и создаёшь pull request. Всё, ты красавчик, и история читается как увлекательный роман, а не как бред сумасшедшего.