Разделить хранилище git для работы над двумя проектами одновременно

Question

Я разрабатываю раму для использования в моих проектах; тем не менее, разработка структуры может зайти так далеко без контекста: то есть мне нужно начать использовать ее в реальных проектах и ​​конкретно посмотреть, что Мне нужно добавить, исправить или настроить (возможно, что-то, что работало в тестовой среде не работают для реальной ситуации, или некоторые вещи не имеют смысла, или я хочу добавить функции).

Прежде всего, так как Framework явно незавершенное, я должен быть уверен, что она обновляться в режиме реального жизненного проекта в другой части, так что я могу вернуться в рамки , отредактируйте его, зафиксируйте, вернитесь в Real-life Project Framework Framework внутри, продолжайте работать с проектом.

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

Теперь я знаю, что инструменты для достижения этого, скорее всего, являются git submodule и git subtree, но оба они довольно сбивают с толку. Субмодуль, в частности, кажется, что он больше ориентирован на подход только для чтения (например, постоянно обновляйте ваши библиотеки): это удовлетворит мое первое требование, но не второе.

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

Answer 1

Любой из двух подходов послужит вам.

Каждый может разрешить то, что вам нужно, отредактировать проект и разместить конкретный контент в отдельных репозиториях.

Оба подхода также несут накладные расходы, чтобы оба проекта работали.

О двух точек вы говорите:

• С подмодулями вы бы иметь хранилище внутри папки другого хранилища. Внешний (Real-Life) сохраняет в файле местоположение вашего репозитория подмодуля (Framework) и используемую текущую фиксацию. Когда вы хотите отредактировать Framework, вы просто переходите в подпапку, где она хранится, и внутри там она должна вести себя так, как если бы вы находились в полностью отдельном репозитории git со своим собственным пультом и историей. После изменения Framework вы вернетесь в Real-Life и обновите ссылки на подмодули. Этот процесс будет выглядеть обычно так:

  Edit files in Framework 
  Move to Framework subfolder 
  Stage, commit, and push changes to Framework repository 
  Go back to Real-Life folder 
  Update Real-Life submodule reference 
  

• С Поддеревами вы работаете с Real-Life и Framework в том же хранилище, сохраняя рамочный код под конкретной подпапкой. Когда вы меняете контент в Framework, вы по-прежнему фиксируете репозиторий Real-Life, как если бы был один проект. Что позволяют инструменты поддерева, так это то, что вы можете изолировать изменения, которые у вас есть в папке Framework, и создать из них набор коммитов, которые существуют отдельно от Real-Life, это коммиты будут содержать изменения только Framework и могут быть перенесены в Framework репозиторий.Этот процесс будет выглядеть следующим образом:

  Edit files in Framework 
  Stage, commit, and push to Real-Life repository 
  Create Framework commits using subtree tools 
  Push Framework specific commits to Framework repository 
  

Если вы все еще не уверены в торговых спинками, которые существуют между этими двумя я бы предположить, что вы идете с помощью подмодулях. Вы найдете больше документации, прецедентов и, как правило, менее сложны. У него есть некоторые недостатки, но, познакомившись с подмодулями, вы могли бы оценить, какие поддеревья предлагают. Подробнее info about submodules.

Answer 2

Ветвление в Git - одна из многих ее замечательных особенностей. Если вы использовали другие системы контроля версий, вероятно, полезно забыть большую часть того, что вы думаете о ветвях - на самом деле, может быть, более полезно думать о них практически как о контекстах, поскольку именно так вы чаще всего будете их использовать. Когда вы проверяете разные ветви, вы меняете контексты, в которых работаете, и вы можете быстро переключаться между различными ветвями и переключаться между ними.

В двух словах вы можете создать ветку с веткой git (branchname), переключиться на этот контекст с помощью git checkout (branchname), записать фиксацию снимков, в то время как в этом контексте, а затем легко переключаться взад и вперед. Когда вы переключаете ветви, Git заменяет ваш рабочий каталог снимком последней фиксации на этой ветке, поэтому вам не нужно иметь несколько каталогов для нескольких ветвей. Вы объединяете ветки вместе с объединением git. Вы можете легко объединить несколько раз из одной ветви с течением времени или поочередно вы можете удалить ветвь сразу же после ее слияния.