Git не может объединить несвязанные истории, мелкий клон

Никогда¹ не используйте --allow-unrelated-histories. Вместо этого углубите (или «неглубоко») ваш клон. Редактировать: согласно комментариям, вам также необходимо преобразовать свой клон в полный клон (в настоящее время это клон с одной ветвью, чего я должен был ожидать, поскольку при использовании --depth во время клонирования по умолчанию также создается клон с одной ветвью).

Слияние в Git зависит от трех коммитов, а не от двух:

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

Когда вы запускаете git merge, аргумент, который вы предоставляете — обычно имя ветки, такое как feature или master — находит середину этих трех: «другой» или --theirs коммит. Текущая или --ours фиксация подразумевается тем, что вы проверили. Третий коммит, общую отправную точку, Git находит самостоятельно. Но Git нужна история, чтобы найти этот коммит.

История в репозитории Git — это не что иное, как коммиты в репозитории. У обычного, не поверхностного клона есть все коммиты², поэтому у него есть вся история. Смысл поверхностного клонирования в том, чтобы намеренно опустить часть истории во имя целесообразности. Для некоторых целей это нормально (и, следовательно, на самом деле целесообразно). Для слияния это не нормально; не делай этого.

Если у вас уже есть неглубокий клон, например, потому что ваша система CI сделала его, рассмотрите возможность запуска:

git remote set-branches origin "*"
git fetch --unshallow

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

Вторая команда перенаправляет обычную операцию git fetch таким образом, чтобы убрать поверхностность. Если окажется, что это требует слишком много системных ресурсов, вы можете в качестве альтернативы использовать git fetch --depth или git fetch --deepen для постепенного добавления дополнительных коммитов в неглубокий репозиторий, пока у вас не будет достаточно истории — достаточно коммитов — для git merge, чтобы найти общую отправную точку. Проблема с этим подходом заключается в том, что нет гарантии, насколько глубокой может быть эта глубина, а это означает, что нет правильного способа выбрать правильную глубину. Это, в свою очередь, подразумевает цикл, в котором вы многократно увеличиваете глубину до тех пор, пока она не станет «достаточной», и каждый раз использует все больше и больше системных ресурсов, чего, по-видимому, вы пытались избежать в первую очередь с помощью поверхностного клонирования.

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

¹Правило для продвинутых пользователей Git: никогда не используйте --allow-unrelated-histories, пока не докажете, что это нормально.

²Помните, суть операции git clone заключается в копировании всех коммитов, но ни одного имени ветки. Для работы Git не нужны имена веток, но нужны коммиты. Нам — людям — не нравится использовать Git без имен веток, поэтому мы всегда заставляем Git создавать некоторые из них, хотя системы CI иногда не обращают на них внимания; мы используем имена веток и/или имена удаленного отслеживания (которые запоминают имена веток некоторых других репозиториев), чтобы найти интересные коммиты. Git также может использовать их, но может напрямую использовать необработанные хэш-идентификаторы, как работают эти системы CI.