Стратегии слияния и слияние со сжатием

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

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

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

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

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

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

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

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

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

Чем полезно слияние сквоша?

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

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

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

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

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

Выберите Фиксация сквош в разделе Тип слияния в диалоговом окне Завершение запроса на вытягивание , чтобы объединить ветвь раздела.

Снимок экрана: закрытие запроса на вытягивание с слиянием в Azure Repos.

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

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

Выберите Squash changes when me mergeing on the Complete pull request (Завершить запрос на вытягивание ), чтобы объединить ветвь раздела.

Снимок экрана: закрытие запроса на вытягивание с слиянием в Azure Repos.

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

Вкладка Файлы в запросе на вытягивание обнаруживает различия при сравнении с тремя сторонами. Алгоритм учитывает последнюю фиксацию в целевой ветви, последнюю фиксацию в исходной ветви и общую базу слияния (т. е. лучший общий предок). Алгоритм — это быстрый, экономичный и надежный метод обнаружения изменений. К сожалению, в некоторых случаях существует несколько истинных баз. В большинстве репозиториев такая ситуация встречается редко, но в крупных репозиториях с большим количеством активных пользователей она может быть распространенной. Вы можете проверить ветви на наличие нескольких баз слияния вручную с помощью git merge-base --all feature master команды . Кроме того, существует автоматическое обнаружение для таких случаев, которое уведомляет вас с сообщением "Обнаружено несколько баз слияния. Отображаемый список фиксаций может быть неполным".

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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