#Как выглядит неисправность
Во время git rebase Git останавливается на коммите и показывает CONFLICT или «could not apply». Это не повод удалять .git или запускать reset --hard: конфликт означает, что один участок файла изменён в двух версиях истории.
#Причины и признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Одни строки менялись в разных коммитахGit не может автоматически объединить изменения | В файле встречаются <<<<<<<, ======= и >>>>>>> | Согласовать итоговый текст файла и продолжить rebase |
| Изменение имени или удалениеОдин коммит удаляет файл, другой меняет | В git status указано deleted by us/them | Определить, сохранять ли файл, до git add или git rm |
#Пошаговое устранение
- 1. Выясните, действительно ли идёт rebaseОткройте терминал в корне репозитория (Git Bash, PowerShell или терминал Linux/macOS), введите git status. Должна появиться строка о rebase и список unmerged paths. Если указан merge/cherry-pick — используйте инструкции для соответствующей операции, а не rebase --continue.
- Чтение статуса; обычные права пользователя, ничего не меняетLinux · Терминал (Bash)КомандаЧтение статуса; обычные права пользователя, ничего не меняет.
git status
- 2. Зафиксируйте исходное состояниеСкопируйте проблемный файл в каталог вне репозитория через проводник; запишите текущую ветку и коммит через git rev-parse. Если копирование невозможно, не редактируйте содержимое до создания копии.
- Только чтениеLinux · Терминал (Bash)КомандаТолько чтение. Во время rebase имя ветки может отсутствовать, это ожидаемо.
git branch --show-currentgit rev-parse HEAD
- 3. Найдите конфликтные файлыПолучите список путей: git diff --name-only --diff-filter=U. Откройте каждый в редакторе с поддержкой UTF-8 и сопоставьте обе части конфликтного блока; не выбирайте автоматически одну сторону во всех файлах.
- Выводит только файлы с неразрешёнными конфликтамиLinux · Терминал (Bash)КомандаВыводит только файлы с неразрешёнными конфликтами.
git diff --name-only --diff-filter=U
- 4. Соберите правильный вариантВ редакторе объедините необходимые строки, удалите все маркеры <<<<<<<, =======, >>>>>>> и сохраните файл. Затем запустите тест проекта; при ошибке сравните с копией и вернитесь к правке. В rebase названия ours/theirs могут означать не те стороны, что при обычном merge.
- 5. Отметьте разрешение и продолжитеПосле проверки выполните git add с конкретным относительным путём, затем git rebase --continue. При следующем конфликте повторите действия; если открылся редактор сообщения коммита, сохраните его и закройте. Не используйте git add . при наличии посторонних файлов.
- Дополнительная команда по темеLinux · Терминал (Bash)С осторожностьюЗамените path/to/file реальным путём; add меняет индекс, continue переписывает локальные коммиты.
git add -- path/to/filegit rebase --continueКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- 6. Проверьте итог или отмените операциюПри успешном завершении git status сообщает о чистом дереве, а git log -5 --oneline показывает новую последовательность коммитов. Если не удаётся восстановить содержание, сначала сохраните все ценные текущие правки отдельно и только потом рассмотрите git rebase --abort — это возвращает состояние до перебазирования.
- Проверка истории; не требует администратораLinux · Терминал (Bash)КомандаПроверка истории; не требует администратора.
git statusgit log -5 --oneline
#Как проверить результат
Откройте исправленный файл, запустите тесты проекта и убедитесь, что git status больше не сообщает о rebase. Если код работает, но коммиты уже опубликованы коллегами, согласуйте дальнейший push отдельно — простой force может затереть их работу.
#Если проблема осталась
Не повторяйте опасные действия на рабочем окружении. Сравните первоначальный симптом с новым состоянием, сохраните обезличенные сообщения и версии компонентов, проверьте резервную копию; перед изменением общей истории Git или данных/сети Docker обратитесь к ответственному администратору проекта.