Как подлить dev ветку в feature ветку в git

Что проверяют

Базовую уверенность в Git и понимание разницы между локальной веткой и её копией на сервере. Следом обычно спрашивают, чем здесь отличается rebase и как вы разрешаете конфликты.

Как отвечать

Покажите короткий путь без лишних переключений:

• git fetch origin: обновляет удалённые ветки, не трогая рабочую копию. Переключаться на dev и делать там pull не нужно, достаточно сливать origin/dev;
• git merge origin/dev: выполняется на своей feature-ветке (переход через git switch, команда есть с Git 2.23). Получается merge-коммит, история не переписывается, поэтому обычный git push проходит без форса;
• конфликты: git status покажет файлы, в них маркеры <<<<<<<, =======, >>>>>>>. После правки git add и git merge --continue или git commit. Если всё пошло не так, git merge --abort вернёт ветку в исходное состояние;
• альтернатива: git rebase origin/dev переносит ваши коммиты поверх свежего dev и даёт линейную историю, но меняет хэши, и дальше нужен git push --force-with-lease. На ветке, где работает кто-то ещё, так делать нельзя;
• повторяющиеся конфликты: git config rerere.enabled true, и Git запомнит, как вы их разрешили.

После слияния соберите проект и прогоните тесты: mvn verify или ./gradlew build. Git сливает текст, а не смысл. Если в dev переименовали метод, который вы вызываете в своей ветке, конфликта не будет, а компиляция сломается.

Где спотыкаются

Сливают локальную dev, которую не обновляли неделю. Слияние проходит чисто, а свежих изменений в ветке нет.

Разрешают конфликт целиком в свою пользу кнопкой в IDE, не читая чужой код. Особенно больно с pom.xml и миграциями: две ветки добавили Flyway-миграцию с версией V12 в файлах с разными именами, Git конфликта не видит, а приложение падает на старте из-за дубля версии.

Делают rebase уже запушенной ветки, с которой работают коллеги, и затем git push --force. Коммиты, которые коллеги успели отправить, пропадают из удалённой ветки.