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

  • Статья

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

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

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

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

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

Слияние Squash

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

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

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

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

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

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

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

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

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

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

Снимок экрана: закрытие запроса на вытягивание с слиянием скваша в 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 в виде нескольких баз (базы слиянием указываются числом 1 и 2):

  • Перекрестные слияния (также известные как кросс-кросс) между различными ветвями (сообщает 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
  • Активное повторное использование ветвь компонента
  • Другие неинтуитивные и свертанные манипуляции с отменить изменения, вишни выбирает и слияние

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

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

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

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

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

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

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

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

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

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

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

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

Следующие шаги