Этап 5 - Разрешение merge conflicts

После слияния feature/task-priority-labels в main начинается реальная командная ситуация: другой разработчик изменяет task-service.js в том же месте, что и вы. Когда одни и те же строки меняются параллельно, Git останавливается и просит вашего решения.

Почему Git не угадывает за нас

Если изменения независимые, Git их объединяет. Если они касаются одной же строки с разными смыслами, автоматический выбор может удалить рабочий вариант. Поэтому Git оставляет оба и просит человека выбрать итоговый результат.

Создание конфликта на примере проекта

Сначала на main создайте docs/ordering.txt в редакторе. Если папки docs еще нет, создайте ее через Finder, Проводник Windows или IDE. В файле должна быть одна строка:

Sort tasks by due date

Сохраните файл и зафиксируйте baseline:

git switch main
git add docs/ordering.txt
git commit -m "docs: define initial ordering policy"

Создайте ветку A. В docs/ordering.txt замените строку на:

Sort tasks by priority then due date

Сохраните и зафиксируйте изменение ветки A:

git switch -c feature/ordering-priority
git add docs/ordering.txt
git commit -m "feature: update ordering by priority"

Вернитесь в main, создайте ветку B и измените тот же файл иначе:

git switch main
git switch -c fix/order-wording

В docs/ordering.txt замените строку на:

Sort tasks by urgency then due date

Сохраните и зафиксируйте изменение ветки B:

git add docs/ordering.txt
git commit -m "fix: align wording with support docs"

Возвращаемся в main и пытаемся слить одну из веток:

git switch main
git merge feature/ordering-priority

Будет конфликт в docs/ordering.txt.

Как правильно разрешать

Откройте файл и отредактируйте маркеры вручную:

<<<<<<< HEAD
Sort tasks by urgency then due date
=======
Sort tasks by priority then due date
>>>>>>> feature/ordering-priority

Оставьте итоговую фразу, например:

Sort tasks by priority then due date

Затем:

git add docs/ordering.txt
git commit

Правила практики

• Сначала читайте business-идею изменений, потом выбирайте текст.
• Не оставляйте маркеры в файле: коммит должен быть чистым.
• После разрешения запускайте проверки.

После явного разрешения история остаётся корректной и прозрачной.

Дополнительные правила для конфликтов в реальном проекте

Перед merge не запускайте изменения с одной и той же зоной файлов двумя разработчиками без явного обсуждения. Даже отличный coder может внести конфликт только потому, что вторая команда не знала о вашей точке расширения.

После разрешения конфликтов полезно добавить поясняющие комментарии в notes или PR description: почему выбран один из вариантов. Это снижает вероятность повторного отката, когда через неделю кто-то вернется к этой точке.

Всегда фиксируйте тестовый прогон после git commit с разрешенным конфликтом.