Сделай патч с этой своей новой ветки, да накати его на другой проект. Про path/diff знаешь же? Разрулишь руками конфликты, если где будут.

path/diff? патч?

Можно пожалуйста поподробнее про патчи и path/diff? Мои знания по гиту ограничиваются созданием новых веток и их слиянием (обычно с помощью merge).

Делаешь

$ git diff <hash коммита с которого начинаются изменения, 307547b212ed3856812ac5feea4aa299b2d040c2 например>

diff --git a/test b/test
index a020e36..a2c0c22 100644
--- a/test
+++ b/test
@@ -1,5 +1,7 @@
 ttt
 1
 2
+5
+4
 3
+6

изменения конкретного коммита

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

diff/patch будет пожалуй самый дубовый и простой подход в данной ситуации.

Про diff/patch согласен с народом, но подумай еще о том, как потом эту фичу в обоих гитах обновлять будешь? Так же патчи таскать?

Мне кажется вы где-то не так с архитектурой замутили. Возможно эту фичу можно было бы вынести куда-нибудь в отдельный модуль и ставить/обновлять его каким-нибудь пакетным менеджером типа npm, composer и т.д.

У нас тоже похожая ситуация, есть engine и есть несколько отдельных проектов на нем. Мы engine выделили в отдельный проект и юзаем как библиотеку, а не плодили ветки от него.

Ситуация, когда подмножество изменений нужно перекатить из одной ветки в другую, подробно разобрана в блоге Реймонда Чена.

Вкратце, нужно создать новую ветку относительно определённого коммита (common merge base), внести в неё соответствующие изменения и замерджить её в обе ветки.

Если не секрет, то с какой целью создавались две изолированные ветки, которые на протяжении года не сливали изменения в одну общую? Если я правильно понял, то там при этом одновременно вносились изменения в одинаковые куски кода?

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

diff/patch будет пожалуй самый дубовый и простой подход в данной ситуации.

Так ведь git cherry-pick именно это и делает - переносит один изолированный патч с одной ветки на другую. Или я что-то неправильно понимаю?

Ситуация, когда подмножество изменений нужно перекатить из одной ветки в другую, подробно разобрана в блоге Реймонда Чена.

А ещё там есть ответ от другой команды, которой не нужно мержить долгоживущие ветки друг в друга (как раз, как ТС'у).

Нет, он переносит коммит, а коммит – это не патч.