BitBucket имеет свои собственные стратегии слияния для запросов извлечения , включая:
Перебазирование, ускоренная перемотка вперед (rebase + merge --ff-only):
Выполняет фиксацию из исходной ветви в целевую ветвь, создавая новый коммит без слияния для каждого входящего коммита.
Быстрая перемотка вперед целевой ветки с полученными коммитами. Эта операция PR не модифицируется этой операцией.
И:
Только перемотка вперед (--ff-only):
Если ветвь источника устарел с целевой веткой, отклонить запрос на слияние. В противном случае обновите целевую ветвь до последней фиксации в исходной ветке.
Либо можно избежать фиксации слияния и получить линейную историю.
Второй предполагает ветку PR был перебазирован локально на рабочей станции разработчика, затем push --force: слияние становится тривиальным.
OP David просит в комментариях :
Так что мне нужно перебазировать каждый второй пул-запрос локально, если два пул-запроса созданы одновременно?
Факт, что два PR создаются "одновременно" не имеет значения в этом процессе.
Один из них будет объединен (без проблем, поскольку он объединяется первым)
Второй не будет объединен (отклонен, поскольку не быстрое слияние)
У разработчика не будет другого выбора, кроме как:
- тянуть мастера, чтобы обновить его с измененной мачтой (здесь первый объединенный PR)
- перебазировать второй пиар локально поверх мачты э-э (разрешение конфликта локально, убедившись, что он все еще работает)
- принудительное нажатие
- слияние второго PR через Интернет GUI (слияние ускоренное, оно будет принято )
Этот процесс, включающий местное примирение, является обычной передовой практикой.