Является ли Git разрешение конфликтов слияния более эффективным, чем другие SCM и инструменты слияния?

Является gitРешение конфликтов слияния по своей природе более эффективно, чем другие SCM (CVS,Subversion и т. д.), а также автономные инструменты слияния? Если так, то почему?

Пояснение: здесь меня больше интересует сам алгоритм - он отличается от простого метода diff3?
Некоторые инструменты утверждают, что в этом они умнее (например, Guiffy), стоит ли включать один из них как инструмент git merge? Является ли Git умнее в определении фрагментов текста, перемещаемых внутри или между файлами? (вместо того, чтобы сообщать о шумных конфликтах. У меня сложилось смутное впечатление об этом из разговора Линуса).

Фон: только что сделал огромное слияние, используя git-svn что привело к половине конфликтов, чем я получил с простой svn merge (первое слияние без отслеживания) .. поэтому я хотел бы понять, почему.

Они похожи на Qs/As, но они больше касаются общей картины процесса и того, как слияние вписывается в него более естественно. С этой целью, git будучи "оптимизированным для слияний" (в отличие от только ветвления), означает ли это на самом деле:

  1. меньше ручных конфликтов - лучшие алгоритмы автоматического разрешения (например, переименование обрабатывается хорошо)
  2. более безопасная операция - автоматическое разрешение оставляет больше / только реальных конфликтов и меньше ложных предупреждений
  3. более быстрая работа - скажем, благодаря модели худых и средних объектов
  4. лучший инструментарий - который делает процесс менее болезненным, например отслеживание слияний на основе DAG, mergetool, запрос / визуализация истории, тайник, ребазинг и т. д.
  5. что-то другое
  6. сочетание вышеперечисленного

? Сейчас меня больше всего интересуют 1 и 2.

Источник

2 ответа

Кроме того, этот более поздний поток (2012) детализирует понятие "авторазрешение" в Git:

Мое определение для "автоматического разрешения":
"Во время слияния файлы рабочего дерева обновляются, чтобы отразить результат слияния... Когда обе стороны внесли изменения в разные области одного и того же файла, git автоматически выберет обе стороны и предоставит вам возможность убедиться, что вы проверьте правильность результатов слияния после того, как git сделал коммит слияния. "

IOW, "автоматическое разрешение" означает, что обе стороны (наша и их) внесли изменения в file(a) так как версия общего предка file(a) и git выбрал обе стороны без возникновения конфликта слияния.
(Причина, по которой я придумал термин "автоматическое разрешение", заключается в том, что в git-merge Вывод термина "Автослияние" также может указывать на то, что изменилась только одна сторона (их) file(a) поскольку общий предок и этот мерзавец просто "перемотали" их file(a) на вершине общего предка file(a).)

Junio ​​C Hamano поднимает в ответ важный момент:

  • знайте, что мерзавец глуп и ошибается в безопасности, делая что-то отдаленно сложное;
  • Знайте, что текстовые несоответствия, возникающие в одном и том же файле, имеют одинаковый риск возникновения семантического конфликта в разных файлах, поэтому выделение "затронул один и тот же файл, но не конфликтовал", что-либо особенное бессмысленно, но в любом случае вероятность наличие такого конфликта достаточно мало, чтобы сначала выполнить слияние (и другие слияния), а затем проверить общий результат, что более эффективно расходует ваше время, потому что в любом случае вы должны посмотреть на результат хотя бы один раз, прежде чем вытолкнуть его.

Обновление через 5 с половиной лет, май 2018 г. (Git 2.18, Q2 2018)

" git mergetools "научился говорить с гифками.

См. Коммит 6ceb658 (05 апреля 2018 г.) Билла Ритчера (``).
(Объединено Юнио С Хамано - gitster - в коммите da36be5, 25 апреля 2018 г.)

mergetools: добавить поддержку guiffy

добавлять guiffy как difftool а также mergetool,

guiffy доступно в Windows, Linux и MacOS

Источник

Я бы хотел быть ошибочным в этом ответе, но... исходя из результатов... эта область мерзости немного развита.

  1. Авто слияние в git не существует. Последняя версия имеет базовую поддержку для выполнения слияния с использованием ваших изменений или их изменений, но это все. В основном, если вы редактируете часть файла, а кто-то другой редактирует ту же часть файла... вы самостоятельно решаете проблему слияния. Доступен формат diff3 (трехстороннее слияние), но я считаю, что унифицированный формат diff является стандартом. Я на самом деле использую araxis в качестве инструмента слияния и настроил его для использования трехстороннего слияния при запуске "git mergetool". Впрочем, из выступления... Я чувствую, что в этой области git сильно отстает.

  2. N / A

Обновление RE: комментарии

Я недостаточно глубоко вник в то, что git считает конфликтом, и что p4 считает конфликтом, но вот что я испытал в обоих случаях.

  • Git не игнорирует пробелы при выполнении слияния... хотя об этом в будущем говорят и о git. p4 может сделать это сейчас. Не игнорировать пробелы - основная проблема, если все члены команды не согласны использовать пробелы или табуляции, и если вы хотите изменить отступ файла... (например, добавив узел xml вокруг других узлов), это быстро устареет,
  • Мне кажется, что когда я сталкиваюсь с конфликтами слияния в файле... части, которые, как говорит git, находятся в конфликте, используя его унифицированный формат diff, больше. Когда изменяется только часть одной строки, она помечает большие части как измененные, и вам нужно визуально отследить изменения между двумя областями унифицированного вывода различий. Хотя вы можете обойти это, используя mergetool. p4 может автоматически разрешать конфликты, даже если редактирует одну и ту же строку.
  • Если вы объединяете долгоживущие ветки тем, вас ждет настоящее удовольствие. Без включения rerere (который по умолчанию выключен) git забудет, что вы уже слили тот файл, который находился в конфликте неделю назад, и попросит вас снова слить его. p4 делает это с легкостью

Мои ответы здесь немного субъективны... но я очень скучаю по тому слиянию, которое у меня было с выступлением.

Источник
Другие вопросы по тегам