Ребейз в Git: как обновить ветку и не потерять работу

Если feature-ветка отстала от main, ребейз перенесёт её коммиты поверх свежей основы и сохранит линейную историю. Примеры ниже рассчитаны на Git 2.45 и новее; на обычной ветке с собственными коммитами операция занимает несколько минут, но при конфликтах время зависит от объёма изменений.

Перед ребейзом: проверьте ветку и рабочее дерево

Ребейз не просто «подтягивает изменения»: Git создаёт новые коммиты на основе другой ветки. Содержание изменений может остаться прежним, но идентификаторы коммитов изменятся. Поэтому сначала проверьте, где вы находитесь и нет ли незакоммиченной работы.

Понадобятся Git 2.45 или новее, локальная копия репозитория и доступ к удалённому репозиторию, если вы собираетесь публиковать результат. Убедиться в версии можно командой git --version. В Git 2.x базовые команды ниже работают одинаково; текст редактора при интерактивном ребейзе зависит от ваших настроек.

git status --short --branch
git branch --show-current
git fetch origin

В выводе первой команды проверьте, что нет изменений, которые вы не готовы потерять или временно отложить. Если рабочее дерево чистое, продолжайте. git fetch обновляет сведения об удалённых ветках, но не меняет вашу текущую ветку.

Upstream — ветка, с которой Git сравнивает вашу локальную ветку или на которую она ориентируется при обновлении и отправке изменений.

Обычный сценарий: перенести feature-ветку на main

Перед ребейзом убедитесь, что целевая ветка называется именно main: в конкретном проекте она может называться иначе. Ниже предполагается, что вы работаете в своей ветке feature, а удалённый репозиторий называется origin.

1. Переключитесь на свою ветку: git switch feature. Проверьте название командой git branch --show-current: она должна вывести feature.

2. Обновите сведения о сервере: git fetch origin. Проверьте, что нужная основа доступна, например командой git log --oneline -5 origin/main: в списке должны быть свежие коммиты проекта.

3. Перенесите свои коммиты: git rebase origin/main. Если команда завершилась без ошибки, проверьте результат командой git status: рабочее дерево должно быть чистым, а ветка — находиться поверх обновлённой основы.

4. Сверьте историю: git log --oneline --graph --decorate -12. Вы должны увидеть коммиты main и свои изменения в одной последовательной линии; если результат неожиданный, не отправляйте его, пока не проверите исходную ветку и историю.

5. Запустите тесты проекта и отправьте ветку на сервер: git push origin feature. Если сервер принял отправку, проверьте страницу ветки или pull request: новые коммиты должны отображаться там.

Последний шаг работает без принудительной отправки, если никто не менял удалённую feature-ветку параллельно. Если Git отклонил push после ребейза, сначала выясните, появились ли на сервере чужие коммиты: не заменяйте обычный push командой с принудительной отправкой вслепую.

Если Git остановился на конфликте

При конфликте Git приостанавливает ребейз и показывает, какие файлы требуют внимания. Это не означает, что коммиты исчезли: операция ещё не завершена. Не переключайтесь на другую ветку и не запускайте поверх этого состояния новый ребейз.

1. Посмотрите список конфликтов командой git status. Git также может вывести сообщение CONFLICT с именами файлов.

2. Откройте указанные файлы и вручную выберите итоговое содержимое. Маркеры <<<<<<<, ======= и >>>>>>> обозначают конфликтующие версии; удалите маркеры после редактирования.

3. Отметьте исправленные файлы командой git add имя-файла. Проверка: git status больше не должен показывать эти файлы как неразрешённые конфликты.

4. Продолжите: git rebase --continue. Если возник следующий конфликт, повторите те же действия для него. Если команда завершилась, проверьте результат и запустите тесты.

Если вы не уверены, что разрешили конфликт правильно, отмените текущую операцию командой git rebase --abort. Git вернёт ветку к состоянию до начатого ребейза. Это безопаснее, чем продолжать с непроверенным содержимым; незакоммиченные изменения до начала операции всё равно стоит заранее сохранить отдельно.

Какой вариант выбрать

Для личной feature-ветки ребейз обычно удобен: история получается последовательной. Для ветки, которую одновременно меняют коллеги, чаще безопаснее merge: он не переписывает уже опубликованные коммиты. Интерактивный ребейз нужен, когда вы хотите привести в порядок собственные коммиты до отправки на ревью.

Выбирайте ребейз для ещё не опубликованной или используемой только вами ветки. Если ветка уже ушла коллегам и в неё могли добавить коммиты, согласуйте переписывание истории. Если главное — не менять опубликованные идентификаторы, используйте merge. Интерактивный режим оставьте для подготовки своих коммитов к ревью.

Интерактивный ребейз: порядок перед ревью

Когда нужно объединить мелкие исправления в один коммит или поправить сообщение, запустите git rebase -i origin/main. Git откроет список коммитов и предложит действия. Оставьте pick у коммита, который хотите сохранить; у следующих коммитов, которые нужно объединить с ним, выберите squash или fixup. Сохраните файл и закройте редактор. Итог проверьте через git log --oneline origin/main..HEAD: в выводе должны остаться ожидаемые коммиты.

Не запускайте интерактивный ребейз наугад: перед сохранением списка убедитесь, что понимаете, какие коммиты попадут в диапазон. Если операция пошла не туда, git rebase --abort отменит её, пока ребейз не завершён. Точные клавиши сохранения зависят от редактора, который открыл Git.

Если ветка уже опубликована

После успешного ребейза обычный git push может быть отклонён: на сервере лежит прежняя история, а локальная ветка содержит новые идентификаторы коммитов. Перед принудительной отправкой ещё раз выполните git fetch origin и проверьте, не появились ли в удалённой ветке чужие изменения.

Если вы уверены, что переписываете только собственную ветку и согласовали это с командой, используйте git push --force-with-lease origin feature. Этот вариант проверяет, что удалённая ссылка не изменилась относительно сведений, которые есть у Git. Он снижает риск затереть чужое обновление, но не заменяет проверку: если вы не знаете, кто менял ветку, остановитесь и выясните это до отправки.

Ребейз безопасен не потому, что Git умеет отменять ошибки, а потому, что вы заранее знаете, чьи коммиты переписываете и проверяете результат до публикации.

Что ломается и что делать дальше

• «cannot rebase: You have unstaged changes». В рабочем дереве остались незакоммиченные изменения. Сохраните их коммитом или временно уберите в stash, затем проверьте git status и повторите ребейз.

• «CONFLICT». Изменения в вашей ветке и в основе затрагивают один участок файла. Разрешите конфликт, выполните git add для исправленного файла и продолжите через git rebase --continue.

• Push отклонён после ребейза. Удалённая ветка не совпадает с локальной. Сначала выполните git fetch origin и выясните, есть ли там коммиты коллег; не используйте --force без проверки.

• Не тот набор коммитов. Возможно, выбрана неверная основа или диапазон для интерактивного ребейза. Если операция ещё идёт, используйте git rebase --abort; после завершения остановитесь и проверьте историю, прежде чем отправлять изменения.

После ребейза сравните список коммитов командой git log --oneline origin/main..HEAD, запустите тесты и посмотрите diff: git diff origin/main...HEAD. Если ветку уже используют коллеги, договоритесь о способе обновления до отправки. Следующий практический шаг — закрепить в команде правило: личные ветки можно перебазировать, общие опубликованные ветки без согласования не переписывают.