Ответ 1

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

Решение 1

Один репозиторий может содержать несколько независимых ветвей, называемых сиротскими ветвями. Сиротные ветки полностью отделены друг от друга; они не обмениваются историями.

git checkout --orphan BRANCHNAME

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

Теперь по какой-то причине git требуется небольшая очистка после сиротской проверки.

rm .git/index
rm -r *

Перед удалением убедитесь, что все выполнено,

Как только сиротская ветка чиста, вы можете использовать ее как обычно.

Решение 2

Избегайте всех хлопот сиротских ветвей. Создайте два независимых репозитория и нажмите их на один и тот же пульт. Просто используйте разные имена ветвей для каждого репо.

# repo 1
git push origin master:master-1

# repo 2
git push origin master:master-2

Ответ 2

Решение 3

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

Запустите все проекты из одного подтвержденного пустого каталога

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

Однако вот план. Начните так, как вам следует запустить любые проекты git, зафиксировав пустой репозиторий, а затем запустите все ваши проекты из того же состояния пустого каталога. Таким образом, вы уверены, что две партии файлов довольно независимы. Кроме того, дайте своим веткам правильное имя и не лениво просто использовать "мастер". Ваши проекты должны быть отдельными, поэтому дайте им соответствующие имена.

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

Создать пустой репозиторий

cd some_empty_directory
git init
touch .gitignore
git add .gitignore
git commit -m empty
git tag EMPTY

Начните свои проекты с нуля.

Работа над одним проектом.

git branch software EMPTY
git checkout software
echo "array board[8,8] of piece" > chess.prog

git add chess.prog 
git commit -m "chess program"

Начать другой проект

всякий раз, когда вам нравится.

git branch thesis EMPTY
git checkout thesis
echo "the meaning of meaning" > philosophy_doctorate.txt
git add philosophy_doctorate.txt 
git commit -m "Ph.D"

Переключаться назад и вперед

Возвращайтесь назад и вперед между проектами, когда захотите. Этот пример восходит к шахматному программному проекту.

git checkout software
echo "while not end_of_game do make_move()" >> chess.prog
git add chess.prog 
git commit -m "improved chess program"

Неотслеживаемые файлы раздражают

Однако при переключении между проектами/ветвями вас будут раздражать неотслеживаемые файлы.

touch untracked_software_file.prog
git checkout thesis 
ls
    philosophy_doctorate.txt  untracked_software_file.prog

Это не непреодолимая проблема

По определению, git не знает, что делать с неотслеживаемыми файлами, и решать вам с ними. Вы можете остановить перемещение неотслеживаемых файлов из одной ветки в другую следующим образом.

git checkout EMPTY 
ls
    untracked_software_file.prog
rm -r *
    (directory is now really empty, apart from the repository stuff!)
git checkout thesis
ls
    philosophy_doctorate.txt

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

Изысканность

$ GIT_AUTHOR_DATE='2001-01-01:T01:01:01' GIT_COMMITTER_DATE='2001-01-01T01:01:01' git commit -m empty

Если при фиксации пустого репозитория указываются одинаковые даты, то независимо созданные пустые коммиты репозитория могут иметь одинаковый код SHA1. Это позволяет независимо создавать два хранилища, а затем объединять их в одно дерево с общим корнем в одном хранилище.

пример

# Create thesis repository. 
# Merge existing chess repository branch into it

mkdir single_repo_for_thesis_and_chess
cd single_repo_for_thesis_and_chess
git init
touch .gitignore
git add .gitignore
GIT_AUTHOR_DATE='2001-01-01:T01:01:01' GIT_COMMITTER_DATE='2001-01-01:T01:01:01' git commit -m empty
git tag EMPTY
echo "the meaning of meaning" > thesis.txt
git add thesis.txt
git commit -m "Wrote my PH.D"
git branch -m master thesis

# It as simple as this ...
git remote add chess ../chessrepository/.git
git fetch chess chess:chess

Результат

Использовать подкаталоги для каждого проекта?

Это также может помочь, если вы храните свои проекты в подкаталогах, где это возможно, например, вместо файлов

chess.prog
philosophy_doctorate.txt 

иметь

chess/chess.prog
thesis/philosophy_doctorate.txt 

В этом случае ваш неотслеживаемый файл программного обеспечения будет иметь вид chess/untracked_software_file.prog. При работе с каталогом thesis вас не должны беспокоить неотслеживаемые файлы шахматных программ, и вы можете встретить случаи, когда вы сможете работать счастливо, не удаляя неотслеживаемые файлы из других проектов.

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

Имена ветвей могут включать символы '/'

Таким образом, вы можете назвать ваши ветки как

project1/master
project1/featureABC
project2/master
project2/featureXYZ

Ответ 3

Я бы использовал git submodules.

посмотрите здесь Git-репозиторий в Git-репозитории

По состоянию на Monorepos я бы предложил Monorepos

• Lerna
• Немного