Есть две ветки - master (прод) и default (тестовая среда). Каждая новая задача - это новая ветка от master. После выполнения она сливается с default, тестируется, потом сливается с master. Создаю новую ветку от master, вношу изменения в 3х файлах, коммичу, сливаю с default - притягиваются коммиты из других веток (те, которые сливались с master недавно) т.е. mercurial, чтобы смотреть в 3 закоммиченных файла, смотрит везде и вываливает кучу конфликтов... Нормальное ли такое поведение системы контроля версий и как это можно исправить?
Asked
Active
Viewed 81 times
0
-
если эти три файла поменялись - да, похоже на обычное дело. – KoVadim Sep 04 '20 at 15:33
-
- Коммиты не "притягиваются" - это гравитация и не притяжение металлов к магнитам.
- При слиянии двух бранчей данные берутся от ближайшего общего предка (и это описано в букваре), а не только "последние мои изменения"
– Lazy Badger Sep 05 '20 at 08:10
2 Answers
1
Это обычное поведение. Если вы одновременно с кем-то вносите изменения в одни и те же файлы, то процедура слияния, используемая по-умолчанию, всегда будет выдавать конфликты. Внешние merge tools могут разрешать некоторые типы конфликтов.
- A - Вы завершили задачу почти одновременно с другим SDE (коммиты 4, 5)
- B - Но потом тот успел раньше вас слить с default и master
- С - В то время как вы сливали с локальным default и разрешали конфликты
- D - Вы хотели сделать push, но оказалось, что на ветке default две головы
- E - Потребуется опять сливать и разрешать конфликты
Вариант, когда вы один сливаете изменения.
- C-2 - После выполнения задачи (коммит 5), вы подтягиваете изменения
- D-2 - Сливаете с default и master и разрешаете конфликты
В принципе, число конфликтов будет одинаковым, только в первом варианте разделено на две части - сначала вы сливаете изменения коммитов 3-5, потом 6-7. А во втором случае - сразу 3-6-5.
По умолчанию используется merge tool :merge. Но по мне, что :merge, что :merge3 работают одинаково плохо. Поэтому я использую kdiff3 - настраивается в .hgrc (или mercurial.ini). Только kdiff3, который поставляется с TortoiseHg весьма устарел, и похоже заброшен. Более свежий можно взять из состава KDE, только там бывают весьма нестабильные версии, надо пробовать разные.
Dmitry Sokolov
- 923
1
Нормальное ли такое поведение системы контроля версий
Да, оно не только нормальное, но и правильное
как это можно исправить?
Никак. Просто навести порядок в организационных процессах в организации (и в головах):
- При merge двух бранчей
- находится последний общий предок
- находятся (и агрегируются) все изменения, произошедшие в бранче-источнике со времени этого changeset-a
- суммарный diff в итоге предыдущего пункта и будет тем, что должно и будет применяться к бранчу-приемнику
- если master ведется правильно (там нет ничего, кроме
branchpoint()+merge()в синтаксисе ревсетов), то никакие "коммиты из других веток" в принципе "притягиваться" не могут
Если нужен более разжеванный до кашицы ответ, то стоит показывать в вопросе больше информации, к примеру DAG проблемной части (hg log -G ...) с указанием, какие такие коммиты из "других ветвей" (какие? откуда?) в каком merge оказались неожиданно участвующими. Тогда будет нормальный ответ, а не гадание
HTH
Lazy Badger
- 324