Два репозитория git в одном каталоге? - PullRequest
74 голосов
/ 12 января 2009

Можно ли иметь 2 репозитория git в одном каталоге? Я думал, что нет, но думал, что я спрошу. По сути, я хотел бы проверить файлы конфигурации моего домашнего каталога (например, .emacs), которые должны быть общими для всех компьютеров, на которых я работаю, но иметь второй репозиторий для локальных файлов (например, .emacs.local), который содержит специфичные для машины конфигурации. Единственный способ, которым я могу придумать, - это иметь локальную конфигурацию в подкаталоге и игнорировать этот подкаталог из основного репозитория git. Любые другие идеи?

Ответы [ 9 ]

138 голосов
/ 26 июня 2013

Эта статья описывает это относительно хорошо:

https://github.com/rrrene/gitscm-next/blob/master/app/views/blog/progit/2010-04-11-environment.markdown

В основном, если вы работаете из командной строки, это проще, чем вы думаете. Предположим, вы хотите 2 репозитория git:

.gitone
.gittwo

Вы можете настроить их так:

git init .
mv .git .gitone
git init .
mv .git .gittwo

Вы можете добавить файл и зафиксировать его только в одном файле:

git --git-dir=.gitone add test.txt
git --git-dir=.gitone commit -m "Test"

Итак, сначала идут параметры для git, затем команда, а затем параметры команды git. Вы можете достаточно легко использовать псевдоним команды git, например:

#!/bin/sh
alias gitone='git --git-dir=.gitone'
alias gittwo='git --git-dir=.gittwo'

Таким образом, вы можете зафиксировать один или другой, набрав немного меньше текста, например gitone commit -m "blah".

Что кажется хитрее, так это игнорирование. Так как .gitignore обычно находится в корне проекта, вам нужно найти способ переключить это без переключения всего корня. Или вы можете использовать .git / info / exclude, но все игнорируемые вами действия не будут зафиксированы или отправлены, что может испортить других пользователей. Другие, использующие любое из репо, могут выдвинуть .gitignore, что может вызвать конфликты. Мне не ясен лучший способ решить эти проблемы.

Если вы предпочитаете инструменты с графическим интерфейсом, такие как TortoiseGit, у вас также могут возникнуть проблемы. Вы можете написать небольшой скрипт, который временно переименует .gitone или .gittwo в .git, чтобы эти предположения были выполнены.

31 голосов
/ 13 января 2009

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

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

Затем на каждой машине извлеките ветку этой машины, которая также будет включать общие файлы конфигурации.

13 голосов
/ 12 января 2009

Посмотрите на подмодуль git .

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

5 голосов
/ 15 марта 2012

RichiH написал инструмент под названием vcsh , который используется для управления точечными файлами с использованием поддельных пустых репозиториев git для помещения более одного рабочего каталога в $ HOME. Ничего общего с csh AFAIK.

Однако, если у вас было несколько каталогов, альтернативой git-submodules (которые являются трудной задачей в лучших обстоятельствах, и использование этого примера не является лучшим из обстоятельств) будет gitslave , что оставляет подчиненные репозитории всегда проверяются на кончике ветки и не требуют трехэтапного процесса для внесения изменений в дочернее репо (проверка на правильную ветку, внесение и принятие изменений, затем переход в суперпроект и фиксация новый субмодуль коммит).

4 голосов
/ 23 августа 2010

Это возможно с помощью переменной GIT_DIR, но имеет много предупреждений, если вы не знаете, что делаете.

3 голосов
/ 21 марта 2014

Мой предпочтительный метод - использовать репо в subdir и использовать рекурсивные символические ссылки:

git clone repo1
cd somerepo
git clone repo2
cd repo2
./build

где ' repo / build ' - файл выглядит так:

#!/bin/bash 
SELF_PATH="$(dirname "$(readlink -f "$0")" )"  # get current dir 
cd .. && git stash && git clean -f -d ''       # remove previous symlinks
cp -sR "$SELF_PATH"/* ../.                     # create recursive symlinks in root

осторожно : не используйте 'git add.'

3 голосов
/ 12 января 2009

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

0 голосов
/ 07 декабря 2017

Отказ от ответственности: Это не реклама. Я разработчик предоставленной библиотеки.

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

0 голосов
/ 04 декабря 2016

Другой вариант - разместить их в отдельных папках и создать символические жесткие ссылки из одной папки в другую.

Например, если есть репозитории:

  1. Repo1 / FolderA
  2. Repo1 / FolderB

И

  1. Repo2 / FolderC

Вы можете использовать символическую ссылку на папки FolderA и FolderB из Repo1 в Repo2. Для окон команда для запуска на Repo1 будет:

User@Repo1$ mklink /J FullPath/Repo2/FolderA FullPath/Repo1/FolderA
User@Repo1$ mklink /J FullPath/Repo2/FolderB FullPath/Repo1/FolderB
User@Repo1$ printf "/FolderA/*\n/FolderB/*\n" >> .gitignore

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

...