Что представляет собой «ветвь со слишком большим количеством изменений» для слияния Github PR rebase?
Какие критерии использует Github, чтобы определить, имеет ли данный PR «слишком много изменений» для слияния с перебазированием?
Недавно я работал над рефакторингом, и после отправки и получения одобрения в PR я получил следующее сообщение из пользовательского интерфейса Github, не позволяющее мне перебазировать изменение:
Эта ветка не может быть перебазирована из-за слишком большого количества изменений
В то время я понятия не имел, каково именно ограничение, поэтому я разделил свой PR ~30 коммитов на 2 изменения ~15 коммитов, что сняло ограничение.
Я нашел вопрос о том же ограничении, но он не фокусируется на том, каковы эти ограничения, вместо этого запрашивая обходные пути:
Сейчас я делаю другое изменение, которое также имеет такое же количество коммитов, и хотел точно знать, какие правила использует Github, чтобы определить, имеет ли данный PR «слишком много изменений», чтобы я мог заранее разделить свои PR соответствующим образом и избежать переделок. как с моей стороны, так и со стороны рецензента.
Я пытался найти официальную документацию по этому вопросу безрезультатно. К сожалению, единственный известный мне способ проверить это — отправить PR и проверить, появляется ли сообщение. Однако это становится невыполнимым, поскольку сообщение отображается только после того, как все проверки прошли успешно, а это означает, что я должен также получить фактические отзывы об изменении, чтобы проверить, можно ли их объединить или нет. Если потом я узнаю, что это невозможно объединить, мне придется создать отдельный PR и разделить изменение, тратя время всех на повторные проверки.
Причиной этого может быть множество различных аспектов (или комбинация нескольких аспектов):
- Количество коммитов
- Количество затронутых файлов
- Количество затронутых линий
- Количество конфликтов с базовой веткой
- так далее
Я использую GH в течение долгого времени и никогда не видел это сообщение до пары недель назад, поэтому я предполагаю, что это либо какая-то новая функция, либо, возможно, ограничение в зависимости от типа плана, используемого моей компанией.
Ответы 1
Это почти наверняка ситуация, основанная на тайм-ауте. GitHub использует libgit2 для выполнения переустановок, и продолжительность перебазирования зависит от количества коммитов, сложности изменений в каждом из этих коммитов и сложности, связанной с репозиторием (размер объектов, которые необходимо искать, и т. д.). . libgit2 не имеет всех оптимизаций обычного Git, но обычный Git не может выполнять перебазирование в пустом репозитории, поэтому требуется использование libgit2.
Таким образом, нет фиксированного ограничения на количество коммитов или сложность, только то, что если это займет больше времени, чем тайм-аут, операция завершится ошибкой, и вы останетесь с этим сообщением. Один из способов избежать этого — использовать регулярные коммиты слияния, которые хотя и не застрахованы от истечения времени ожидания, но с меньшей вероятностью сделают это, потому что слияние включает только три коммита, а не сколько их в вашей ветке.
Я не. Я один из тех, кому нужны базовые внутренние API, но я не контролирую ни это сообщение, ни веб-интерфейс. Я не могу на 100% сказать, что это связано с тайм-аутом, но я не могу придумать никакой другой причины, по которой это сообщение может появиться. Если вы хотите большей определенности, вам придется обратиться в службу поддержки GitHub. Однако я уверен, как GitHub выполняет перебазирование.
Есть ли у вас какие-либо ссылки на информацию, которую вы предоставляете? Что касается коммита слияния, я знаю, что выполнение коммита слияния не имеет этой проблемы, но я хотел иметь линейную историю в этих конкретных случаях, поэтому я целенаправленно избегал этого варианта слияния.