Что представляет собой «ветвь со слишком большим количеством изменений» для слияния Github PR rebase?

Какие критерии использует Github, чтобы определить, имеет ли данный PR «слишком много изменений» для слияния с перебазированием?

Недавно я работал над рефакторингом, и после отправки и получения одобрения в PR я получил следующее сообщение из пользовательского интерфейса Github, не позволяющее мне перебазировать изменение:

Эта ветка не может быть перебазирована из-за слишком большого количества изменений

В то время я понятия не имел, каково именно ограничение, поэтому я разделил свой PR ~30 коммитов на 2 изменения ~15 коммитов, что сняло ограничение.

Я нашел вопрос о том же ограничении, но он не фокусируется на том, каковы эти ограничения, вместо этого запрашивая обходные пути:

Сейчас я делаю другое изменение, которое также имеет такое же количество коммитов, и хотел точно знать, какие правила использует Github, чтобы определить, имеет ли данный PR «слишком много изменений», чтобы я мог заранее разделить свои PR соответствующим образом и избежать переделок. как с моей стороны, так и со стороны рецензента.

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

Причиной этого может быть множество различных аспектов (или комбинация нескольких аспектов):

  • Количество коммитов
  • Количество затронутых файлов
  • Количество затронутых линий
  • Количество конфликтов с базовой веткой
  • так далее

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

Шаблоны Angular PrimeNg
Шаблоны Angular PrimeNg
Как привнести проверку типов в наши шаблоны Angular, использующие компоненты библиотеки PrimeNg, и настроить их отображение с помощью встроенной...
Создайте ползком, похожим на звездные войны, с помощью CSS и Javascript
Создайте ползком, похожим на звездные войны, с помощью CSS и Javascript
Если вы веб-разработчик (или хотите им стать), то вы наверняка гик и вам нравятся "Звездные войны". А как бы вы хотели, чтобы фоном для вашего...
Документирование API с помощью Swagger на Springboot
Документирование API с помощью Swagger на Springboot
В предыдущей статье мы уже узнали, как создать Rest API с помощью Springboot и MySql .
Начала с розового дизайна
Начала с розового дизайна
Pink Design - это система дизайна Appwrite с открытым исходным кодом для создания последовательных и многократно используемых пользовательских...
Шлюз в PHP
Шлюз в PHP
API-шлюз (AG) - это сервер, который действует как единая точка входа для набора микросервисов.
14 Задание: Типы данных и структуры данных Python для DevOps
14 Задание: Типы данных и структуры данных Python для DevOps
проверить тип данных используемой переменной, мы можем просто написать: your_variable=100
1
0
79
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Это почти наверняка ситуация, основанная на тайм-ауте. GitHub использует libgit2 для выполнения переустановок, и продолжительность перебазирования зависит от количества коммитов, сложности изменений в каждом из этих коммитов и сложности, связанной с репозиторием (размер объектов, которые необходимо искать, и т. д.). . libgit2 не имеет всех оптимизаций обычного Git, но обычный Git не может выполнять перебазирование в пустом репозитории, поэтому требуется использование libgit2.

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

Есть ли у вас какие-либо ссылки на информацию, которую вы предоставляете? Что касается коммита слияния, я знаю, что выполнение коммита слияния не имеет этой проблемы, но я хотел иметь линейную историю в этих конкретных случаях, поэтому я целенаправленно избегал этого варианта слияния.

julealgon 21.11.2022 22:25

Я не. Я один из тех, кому нужны базовые внутренние API, но я не контролирую ни это сообщение, ни веб-интерфейс. Я не могу на 100% сказать, что это связано с тайм-аутом, но я не могу придумать никакой другой причины, по которой это сообщение может появиться. Если вы хотите большей определенности, вам придется обратиться в службу поддержки GitHub. Однако я уверен, как GitHub выполняет перебазирование.

bk2204 22.11.2022 02:02

Другие вопросы по теме