Проблема в том, что вы пытаетесь отправить новый коммит на удаленный мастер, из которого недоступен коммит, находящийся в данный момент на удаленном мастере.В первый раз, когда вы это сделали, предположительно, на пульте не было коммитов.Итак, вы начали с
O -- x ... x -- A <--(master)
в вашем локальном репо.Вы создаете потерянную ветвь и нажимаете, так что теперь у вас есть
O -- x ... x -- A <--(master)
R1 <--(pub_sync)(p-repo/master)
Теперь вы не сказали явно, как вы делали это во второй раз, но похоже, что вы либо удалили локальную ветку pub_sync
,или сделал что-то эквивалентное.(Потому что в противном случае, если выполнить те же действия, что и выше, создание ветки не удастся.) Поэтому после того, как вы выполнили какую-то разработку и еще один новый checkout --orphan
, у вас будет
O -- x ... x -- A -- x .. x -- B <--(master)
R1 <--(p-repo/master)
R2 <--(pub_sync)
Возможно, это то, что вы имели в виду в git«не зная», что новая сиротская ветвь связана с удаленным master
, в этом случае вы правы.Теперь вы могли бы принудительное нажатие pub_sync
, но я не рекомендую этого по двум причинам: во-первых, принудительное нажатие не должно быть обычной частью вашего рабочего процесса.Во-вторых, поскольку вы храните релизы в репозитории, я предполагаю, что вы хотите сохранить там историю релизов.
Что вам действительно нужно, так это создать R2
как дочерний элемент R1
.
В другом ответе кто-то предлагает слияние сквоша;проблема в том, что вам придется вручную отслеживать базу слияния.Есть шаблон, по которому вы можете следовать, когда вы сначала делаете истинные слияния с промежуточной ветвью, а затем повторно применяете только этот патч к конечной ветке выпуска;но это, вероятно, излишне для вашего случая использования.В качестве альтернативы вы можете создать ссылку для представления базы слияния, и не забывайте перемещать ее после каждого слияния в сквош.Кроме того, вопреки инструкциям из другого ответа, если вы не хотите рисковать, случайно выставив dev-коммиты в prod-репо, вам нужно будет выполнить слияние сквоша на стороне dev и выдвинуть только результат.
Или вы можете использовать commit-tree
;это тоже немного хлопотно, но, возможно, можно было написать сценарий или создать псевдоним.Вы бы не удалили / переориентировали синхронизирующую ветку;поэтому, начиная с
O -- x ... x -- A -- x .. x -- B <--(master)
R1 <--(pub_sync)(p-repo/master)
, вы бы
git checkout pub_sync
git merge $(git commit-tree -p HEAD -m "commit message" master)
git push p-repo pub_sync:master