Конфликты

Когда возникает конфликт

Git умеет автоматически сливать изменения, если они не пересекаются: ты поменял первые 10 строк файла, коллега — последние 50, git склеит сам.

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

Самые частые места конфликтов:

• package.json / go.mod / Cargo.toml — блок зависимостей,
• CHANGELOG.md — все добавляют сверху,
• конфиги, в которые правят и тебя, и параллельная ветка.

Что появляется в файле

При конфликте git вставляет в файл маркеры:

common code
<<<<<<< HEAD
твоя версия (то, что в текущей ветке)
=======
чужая версия (то, что в той, которую вливаешь)
>>>>>>> feature/login
more common code

• <<<<<<< HEAD — начало твоего блока,
• ======= — разделитель,
• >>>>>>> feature/login — конец чужого блока + имя ветки (или SHA при rebase).

Примечание про rebase: при git rebase стороны меняются местами. HEAD там не твоя ветка, а та, на которую ты ребейзишься (upstream), а «чужой» блок - это уже твои коммиты, которые перекладываются сверху.

Файл сейчас сломан: эти маркеры — не валидный код ни на одном языке. Запускать его нельзя, пока не разрулишь.

Как разрулить

Три шага:

1. Открой файл, прими решение: оставить твоё, оставить чужое, объединить руками. Иногда правильный ответ — переписать оба варианта заново.
2. Убери все три маркера (<<<<<<<, =======, >>>>>>>) и ненужные блоки.
3. Скажи git'у "я разрулил": git add <файл>.

Когда все конфликтные файлы добавлены, продолжи операцию:

# если был merge
git commit          # git сам подставит merge-сообщение
# если был rebase
git rebase --continue

Команда статуса во время merge

git status во время незавершённого merge показывает специальный раздел:

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   src/app.ts
        both modified:   src/config.ts

both modified — файл изменили обе ветки, в нём маркеры конфликта. После git add <файл> он переходит в "modified": резолв засчитан.

Если разрешение не идёт

Откатить всё назад:

git merge --abort
git rebase --abort

После этого ты в том же состоянии, в каком был до старта merge/rebase. Никакого ущерба. Это аварийный выход, не бойся им пользоваться.

Mergetool

Когда конфликтов много или они нетривиальные, удобно открыть визуальный mergetool: показывает три панели (наша версия, общий предок, их версия) и позволяет тыкать строчки.

git mergetool

Скорее всего, на проде ты будешь работать через IDE: VS Code, IntelliJ и им подобные. Они открывают встроенный 3-way merge с кнопками "Accept yours", "Accept theirs", "Keep both" и подсветкой блоков.

Ловушка: маркер в коммите

Бывает так: разрулил два конфликта из трёх, забыл про третий, сделал git add . && git commit. В коммит ушёл файл с <<<<<<< внутри. CI обычно ловит такое (тесты падают, линтер ругается), но иногда пролезает, и продакшен встаёт.

Профилактика:

• grep -rn '<<<<<<<' . из корня репо (или git diff --check, который показывает оставшиеся маркеры конфликтов),
• линтер языка обычно сразу сообщит про невалидный синтаксис,
• IDE подсвечивают конфликтные маркеры красным.

В команде стоит настроить pre-commit hook или CI-проверку, которая явно фейлит коммит/MR с маркерами.

Что важно запомнить

Конфликт = пересечение строк в одной и той же области.

Маркеры <<<<<<<, =======, >>>>>>> нужно убрать все при резолве.

git add <файл> отмечает резолв. Дальше git commit (для merge) или git rebase --continue.

--abort отменяет операцию полностью, можно начать заново.

В следующем уроке — короткий квиз, и тема Git закрыта.