Поддельный разветвление собственного репо для удобства обслуживания

Question

Я не уверен, как точно описать проблему, поэтому я буду использовать пример, скажем, у меня есть следующее:

• RepoA - оригинальный репозиторий с некоторым базовым кодом, библиотеками, фреймворком, структурой папок и т. Д.
• RepoB - в идеале - ветвь / ветвь ... но я не могу разветвлять ваши собственные репо, и я хочу отдельное репо, поэтому ветвь не работает

Цель состоит в том, чтобы работать с RepoB и иметь возможность merge изменений, которые были сделаны внутри RepoA в коде, поэтому, если новая функция разработана на RepoA, я могу просто объединить ее с RepoB и продолжить разработку. По сути, это «ветка» другого репо.

Это как-то возможно?

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

РЕДАКТИРОВАТЬ: Согласно комментариям

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

Затем для каждого проекта я бы создал определенный репозиторий и перетащил в фреймворк из-за отсутствия лучших слов. Но я хочу иметь возможность «объединить» дополнительные вещи, которые могут быть добавлены в инфраструктуру на более позднем этапе в репо.

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

Answer 1

Так что после некоторого возни с тем, что предложил Мохана Рао, мне удалось получить то, что мне нужно.

Единовременное использование

Мы делаем всю нашу работу внутри RepoB, скажем, в основной ветке:

git remote add base <link-to-RepoA>
git checkout -b new-feature-import
git pull base master --allow-unrelated-histories
git checkout master
git merge new-feature-import
git branch -D new-feature-import

Сохранение для будущего использования:

git remote add base <link-to-RepoA>
git fetch base
git checkout -b base-integration
git branch --set-upstream-to=base/master
git pull --allow-unrelated-histories
git checkout master
git merge base-integration

Со вторым методом, позволяющим вам переключиться на ветку на более позднем этапе и просто сделать попытку получить последние изменения. Очевидно, что любые конфликты слияний вам нужно будет разрешить, и, очевидно, вам не следует переходить из ветви base-integration обратно в RepoA, если вы решите воспользоваться этим «более удобным» решением.