[ad_1]
Был выпущен Git 2.33, включающий новый необязательный процесс слияния, называемый merge-ort, который, как надеется команда, станет стандартным в следующей версии.
Релизы Git относительно часты. Git 2.31 был выпущен в марте, а Git 2.32 – в июне. Согласно объявлению о выпуске, версия 2.33 «не имеет большого количества изменений и новых функций, ожидаемых конечным пользователем», за исключением исправлений и внутренних улучшений, но есть одно важное изменение, описываемое как «бэкэнд новой стратегии слияния».
Речь идет о стратегии merge-ort, где ort означает «якобы рекурсивный близнец», по словам ее создателя Элайджи Ньюрена.
Стратегия слияния – это механизм, используемый для объединения кода из нескольких версий одной и той же кодовой базы. Слияние является важной особенностью распределенных систем контроля версий, поскольку оно позволяет избежать необходимости блокировать основную версию при редактировании извлеченной копии. Механизмы слияния работают, сравнивая содержимое файла с содержимым его предка, чтобы идентифицировать измененные разделы, а затем сравнивая измененные разделы одного файла с таковыми другого.
Однако не всегда может быть один файл-предок, и в этом случае можно использовать рекурсивное слияние для объединения предков-кандидатов, а затем рассматривать объединенный файл как предка. «Сообщается, что это приводит к меньшему количеству конфликтов слияния, не вызывая ошибочных слияний, благодаря тестам, выполненным на фактических коммитах слияния, взятых из истории разработки ядра Linux 2.6», – говорится в документации. Рекурсивное слияние – это значение по умолчанию в Git. Другой, называемый осьминогом, предназначен для объединения файлов с более чем двумя головками и используется по умолчанию при объединении более чем одной ветки.
Старший инженер-программист GitHub Тейлор Блау сказал, что слияние-рекурсивное имеет «несколько ошибок за годы, связанные с хитрыми угловыми случаями» и что в некоторых крупных случаях он «может быть очень медленным». По его словам, Merge-ort «представляет собой переписывание с нуля», в котором используются те же концепции, но «решаются многие давние проблемы с правильностью и производительностью».
По его словам, в одном из примеров операция слияния была более чем в 9000 раз быстрее, чем рекурсивная слияние, а в другом «очень сложном» случае она была более чем в 500 раз быстрее. Он также сказал, что merge-ort лучше оптимизирован, чтобы не иметь доступа к неизменным частям дерева исходного кода, и лучше подходит для интеграции с другими инструментами. В этом посте Ньюрен резюмирует преимущества слияния с точки зрения корректности, расширяемости и производительности. Merge-ort можно использовать в Git 2.33 с помощью команды:
merge -s ort
В 2.33 есть и другие более мелкие изменения, в том числе улучшения в команде send-email, руководство по гендерно-нейтральной документации и другие обновления документации, «чтобы не предполагать, что пользователи принадлежат к определенному полу».
Git, разработанный Линусом Торвальдсом для кода Linux, сейчас доминирует в системах контроля версий, но он не самый простой или интуитивно понятный в использовании. Д-р Ричард Хипп, создатель менеджера баз данных Sqlite, а также конкурирующего менеджера управления версиями под названием Fossil, считал команду Git Rebase вредной и, среди прочего, не одобрял невозможность редактировать комментарии при регистрации. «Ментальная модель Git излишне сложна», – написал он на веб-странице, озаглавленной «Почему SQLite не использует Git».
Git 2.33 не проще, чем раньше, но более быстрое и правильное слияние – однозначное улучшение. ®
[ad_2]
