Поделиться через

Стратегии слияния и сквош-слияние

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Пример регулярного слияния из запроса на вытягивание.

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

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

Предпосылки

Категория Требования
доступ к проекту Член проекта .
Разрешения — Просмотр кода в частных проектах: по крайней мере базовый доступ.
— Клонирование или внесение вклада в код в частных проектах: Участник группы безопасности для участников или наличие соответствующих разрешений в проекте.
— Задайте разрешения ветви или репозитория: управление разрешениями для ветви или репозитория.
— Измените ветвь по умолчанию: . Измените политики и разрешения для репозитория.
— Импорт репозитория: член группы безопасности администраторов проекта или разрешение уровня проекта Git на создание репозитория установлено в «Разрешить» . Дополнительные сведения см. в разделе "Настройка разрешений репозитория Git".
Сервисы; Repos включено.
Инструменты Необязательно. Используйте команды az repos: Azure DevOps CLI.

Примечание.

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

Категория Требования
доступ к проекту Член проекта .
Разрешения — Просмотр кода: доступ уровня Basic хотя бы .
— Клонирование или участие в коде: член группы безопасности участников или обладатель соответствующих разрешений в проекте.
Сервисы; Repos включено.

Сквош-слияние

Объединение Squash — это параметр слияния, позволяющий сжать журнал разделов Git при завершении запроса на вытягивание. Вместо того чтобы добавлять каждый коммит из тематической ветви в историю ветви по умолчанию, слияние сквош объединяет все изменения файлов в один новый коммит на ветви по умолчанию. Фиксация слияния методом Squash не содержит ссылки на тематическую ветку. Он создает новый коммит, содержащий все изменения из тематической ветки. Рекомендуется удалить ветвь раздела, чтобы предотвратить путаницу.

Схема сквош-слияния в пулл-реквестах в Azure Repos.

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

Чем полезно слияние типа "squash"?

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

Рекомендации при слиянии скваша

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

Завершение запросов на вытягивание с помощью слияния squash

При завершении запроса на вытягивание в Azure Repos можно выбрать слияние.

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

Снимок экрана закрытия pull-запроса с объединением коммитов в Azure Repos.

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

Вкладка "Файлы " в пул-реквесте обнаруживает диффы по трехстороннему сравнению. Алгоритм учитывает последний коммит в целевой ветви, последний коммит в исходной ветви и их общую базу слияния, например, лучший общий предок. Алгоритм — это быстрый, экономичный и надежный метод обнаружения изменений. К сожалению, в некоторых случаях существует более одной истинной основы. В большинстве репозиториев эта ситуация редка, но в больших репозиториях с большим количеством активных пользователей это может быть распространено. Можно вручную проверить, существуют ли несколько баз слияния между ветками. Для этого выполните git merge-base --all feature master команду. Azure DevOps обнаруживает существование нескольких баз слияния для каждого PR. При обнаружении этих данных Azure DevOps отображает сообщение "Обнаружено несколько баз для слияния." Список фиксаций, отображаемых, может быть неполным для PR. Хотя Azure DevOps определяет несколько баз слияния, он не проверяет, была ли потенциальная база слияния уже объединена или нет. Такая проверка выполняется git merge-base. Именно поэтому Azure DevOps может отображать сообщение, даже если git merge-base сообщает только одну базу слияния.

Примечание.

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

В следующих примерах сценарии выявляются Azure DevOps как имеющие несколько баз, при этом базы слияния обозначены цифрами один и два.

  • Перекрестные слияния (также известные как межкрестные) между различными ветвями (сообщает Azure DevOps и git merge-base)
---1---o---A
    \ /
     X
    / \
---2---o---o---B
  • Слияние одной ветви с двумя другими (сообщается в Azure DevOps, но без использования git merge-base для исключения слияния с базой 2)
---1---o---o---o---A
    \         /
     \-------2
      \       \
       \---o---o---o---B
  • Обработка последствий откатов основной ветки, например исправление коммита объединения.
*   42bb2d2 (HEAD, A) Amended merge commit
|\  
| | *   67c9bb8 (other) Merge branch 'A' into B
| | |\  
| |/ /  
|/| /   
| |/    
| * fa78e32 add second commit
* | 15845c9 add first commit
|/  
* 6a52130 add init
  • Активное повторное использование ветвей компонентов
  • Другие неинтуитивные и запутанные манипуляции с откатами, выборочными коммитами и слияниями.

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

См. официальную документацию по Git для получения дополнительных сведений.

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

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

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

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

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

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

Ниже приведены общие советы по предотвращению проблемы нескольких баз объединения:

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

Что делать, если проблема с несколькими базами слияния возникнет вновь

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

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