Стратегии слияния и слияние Squash

Azure Repos | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2017

По завершении запроса на включение внесенных измененийвы объединяете ветвь раздела в ветвь по умолчанию, как правило, . Это слияние добавляет фиксации ветви раздела в основную ветвь и создает фиксацию слиянием для согласования любых конфликтов между ветвью по умолчанию и темой раздела. Комментарии и обсуждения в запросе на вытягивание предоставляют дополнительный контекст для изменений, внесенных в ветвь раздела.

Example of a regular merge from a pull request.

Журнал фиксации в ветви (или другой ветви по умолчанию) не соответствует прямой строке из-за соответствующей истории ветвей разделов. По мере роста проекта число ветвей разделов, обрабатываемых в одно и то же время, увеличивается, что делает историю ветвей по умолчанию гораздо сложнее.

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

Слияние Squash

Слияние Squash — это вариант слияния, позволяющий сжать журнал Git ветвей разделов при выполнении запроса на включение внесенных изменений. Вместо каждой фиксации в ветви раздела, добавляемой в журнал ветви по умолчанию, Squash MERGE добавляет все изменения файла в одну новую фиксацию в ветви по умолчанию.

Diagram of squash merging in pull requests in Azure Repos.

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

Как Squash слияние?

Слияние Squash сохраняет историю ветвей по умолчанию без каких-либо изменений в Рабочей группе. Участники ветви разделов работают над тем, как они хотят в ветви раздела, а ветви по умолчанию сохраняют линейную историю с помощью Squash слияний. Журнал фиксации main ветви, обновленной с помощью слияний Squash, имеет одну фиксацию для каждой объединенной ветви. Вы можете пошагово пройти эту историю, чтобы узнать, как именно выполнялась работа.

Рекомендации по Squash слиянию

Слияние Squash сжимает историю изменений в ветви по умолчанию, поэтому важно работать с командой, чтобы решить, когда следует Squash слияние, или если необходимо сохранить полную историю фиксаций ветви раздела. При слиянии Squash рекомендуется удалить исходную ветвь. Удаление исходной ветви предотвращает путаницу, так как сама ветвь раздела не выполняет ее слияние в ветвь по умолчанию.

Выполнение запросов на вытягивание с помощью слияния Squash

Вы можете Squash слияние при завершении запроса на включение внесенных изменений в Azure Repos.

Выберите Squash Commit (применить фиксацию ) в разделе тип слияния в диалоговом окне полный запрос на вытягивание , чтобы Squash объединить ветвь раздела.

Screenshot of closing a pull request with a squash merge in Azure Repos.

Выполнение запросов на вытягивание с помощью слияния Squash

Вы можете Squash слияние при завершении запроса на включение внесенных изменений в Azure Repos.

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

Screenshot of closing a pull request with a squash merge in Azure Repos.

Несколько баз слияния

Вкладка файлы в запросе на включение внесенных изменений обнаруживает различия с помощью сравнения на основе трех сторон. Алгоритм принимает во внимание последнюю фиксацию в целевой ветви, последнюю фиксацию в исходной ветви и общую базовую базу слияния. Алгоритм — это быстрый, экономичный и надежный метод обнаружения изменений. К сожалению, в некоторых случаях существует более одного истинного основания. В большинстве репозиториев эта ситуация случается редко, но в больших репозиториях с множеством активных пользователей это может быть распространено.

Следующие сценарии могут вызвать несколько баз:

  • Перекрестное слияние между различными ветвями
  • Активное повторное использование ветвей компонентов
  • Обработка афтермасс для основной ветви возвращает
  • Другие неинтуитивные и сложные манипуляции с возвратами, выборочным отбором и слиянием

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

Потенциальные риски безопасности при объединении из нескольких баз

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

Как устранить проблему с несколькими объединенными базами слияния

Наличие нескольких баз слияния не всегда является плохим, но следует проверить, что все правильно. Чтобы удалить несколько баз слияния, свяжите ветви с одним общим предком. Либо воссоздать ветвь на целевом объекте, либо объединить целевой объект в Main. Эти действия изменяют предупреждающее сообщение и помогают проверить, правильно ли были внесены фактические изменения.

Одним из подходов является Программный сброс и скрытие хода выполнения перед изменением базового или объединенного процесса. Затем можно создать новую ветвь или изменить ее базовую точку и применить изменения из четкой точки. Этот процесс может потребовать принудительной отправки в удаленное приложение, если изменения уже существуют.

Как избежать проблемы множественного слияния баз

Ниже приведены общие советы по устранению проблем с множественным слиянием.

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

Что делать при повторном появлении проблемы множественного слияния баз

В больших репозиториевах с множеством активных участников эта проблема может быть особенно неудобной. Даже если вы получаете несколько баз данных с помощью слияния, ситуация может появиться снова. Если кто-то закрывает запрос на вытягивание всегда, он может воссоздать ситуацию. Несмотря на то что политики сборки и тесты выполняются, нет необходимости завершать запрос на включение внесенных изменений. Может помочь сброс и запуск новой ветви. Если ничего не изменилось, изменения, скорее всего, будут очевидны, даже если ситуация повторяется.

Дальнейшие действия