Принцип слияния (вкратце)
- Если ветка A в точке X и ветка B — в точке Y, Git находит общий предок (merge base) и делает либо:
- fast‑forward: если одна ветка содержит другую — просто сдвигает указатель;
- three‑way merge: создаёт новый merge‑коммит, сравнивая base, A и B;
- octopus/специальные стратегии для нескольких веток.
- Технически мердж — сравнение изменений относительно общего предка и попытка автоматически применить обе правки.
Типы конфликтов и причины
- Текстовые конфликты (overlapping edits): одни и те же строки изменены по-разному в обеих ветках — самый частый.
- Delete/modify: файл удалён в одной ветке и изменён в другой.
- Rename/rename или rename/modify: переименование в обеих ветках или переименование + изменение.
- Binary conflicts: двоичные файлы нельзя сливать построчно.
- Конфликты форматирования/whitespace, концов строк (CRLF), executable bit.
- Субмодули: разные коммиты в submodule.
- Логически конфликтующие изменения (semantic), которые Git не считает конфликтом, но ломают поведение.
Как обнаружить конфликт
- После `git merge` или `git rebase` Git пометит конфликтные файлы; `git status` покажет список.
- Можно посмотреть индекс с конфликтами: `git ls-files -u` (стадии $1$, $2$, $3$: базовая, "ours", "theirs").
Разрешение конфликтов (практически)
- Общий алгоритм:
1. Открыть конфликтные файлы и выбрать/сделать корректный итог (удалить маркеры `<<<<<<>>>>>>`).
2. Локально протестировать.
3. `git add ` для пометки как решённого.
4. `git commit` (при merge) или `git rebase --continue`.
- Быстрые команды:
- принять нашу версию: `git checkout --ours -- ` или `git restore --source=MERGE_HEAD --staged --worktree ` (варианты в разных версиях Git);
- принять их версию: `git checkout --theirs -- `.
- Инструменты: `git mergetool` (Meld, KDiff3, VSCode), `git diff --merge`, `git log --merge`.
- Варианты стратегии при merge:
- `git merge --no-ff` — гарантировать merge‑коммит;
- `git merge -s recursive -X patience` / `-X ignore-space-change` / `-X rename-threshold=` — тонкая настройка алгоритма recursive;
- `-X ours` (для recursive) — при конфликте выбирать "наши" изменения (опасно, теряет "их"); аналог `-X theirs` для противоположного эффекта.
- Для двоичных файлов — хранить политики (lock файловая блокировка) или хранить в LFS.
- Автоматизация разрешений: `git rerere` — запоминает как вы разруливали конфликт и при повторной схожей ситуации применяет решение.
Индивидуальные приёмы и рекомендации
- Частые интеграции из основного бранча уменьшают вероятность крупных конфликтов.
- Малые, атомарные PR/коммиты проще мёржить.
- Включить CI, чтобы не допускать регрессий при разрешении.
- Использовать feature flags для интеграции незавершённого функционала.
- Нельзя переписывать публичную историю; если ветка публичная — избегать force‑push после общего ребейза без договорённости.
Рабочие процессы для крупных распределённых команд
- Git‑flow
- Структура: `master` (production), `develop` (интеграция), feature/*, release/*, hotfix/*.
- Плюсы: чёткая модель релизов, удобна когда релизы редки и требуется стабильность.
- Минусы: много долгоживущих веток, частые мержи между `develop` и `feature` → больше конфликтов и сложность координации в больших распределённых командах.
- Подходит: команды с классическим релизным циклом, отдельными релиз‑менеджерами.
- Trunk‑based development (TBD)
- Идея: все активно интегрируются в один главный бранч (`main`/`trunk`), фичи маленькие и короткоживущие; более крупные фичи — через feature flags.
- Плюсы: минимизирует долгие слияния, улучшает CI/CD, уменьшает количество конфликтов и интеграционных сюрпризов; лучше для масштабируемой, распределённой разработки и частых деплоев.
- Минусы: требует сильной автоматизации тестов, дисциплины по маленьким PR, feature flags и хороших процессов обзора кода.
- Рекомендуется для больших команд, ориентированных на непрерывную доставку.
- Гибридный подход
- Короткоживущие feature‑ветки + регулярный ребейз/мердж с trunk, protected main, PR с обязательным CI и код‑ревью.
- Для релизных циклов — временные release ветки, но только на короткое время.
Резюме — что выбрать и как уменьшить конфликты
- Для крупной распределённой команды обычно эффективнее trunk‑based с короткими ветками, CI, feature flags, protected branches и автоматическими проверками.
- Git‑flow пригоден при формальном релизном процессе и командах, где релизы централизованы.
- В любом случае: поощрять маленькие изменения, частую синхронизацию с основой, хорошую автоматизацию тестов и использование `git rerere` + mergetool для ускорения разрешения конфликтов.