Как мне работать с Git-репозиторием в другом репозитории?

284

У меня есть репозиторий Git, в котором я храню все свои основные файлы JavaScript и CSS и сценарии, которые я буду использовать в различных проектах.

Если я создаю новый проект в своем собственном Git-репозитории, как мне использовать файлы JavaScript из моего медиа-репозитория в моем новом проекте таким образом, чтобы мне не приходилось обновлять обе копии скрипта при внесении изменений ?

Брент О'Коннор
источник
Пожалуйста, смотрите ответ поддерева ниже от @ ruslan-kabalin. Примечание: хуки pre-commit (или overcommit ) являются одним из способов справиться с возражением, высказанным Robert Dundon
Hedgehog

Ответы:

348

Ключ это git submodules .

Начните читать главу « Подмодули» Git Community Book или Руководства пользователя.

Скажем, у вас есть хранилище PROJECT1, PROJECT2 и MEDIA ...

cd /path/to/PROJECT1
git submodule add ssh://path.to.repo/MEDIA
git commit -m "Added Media submodule"

Повторите на другом репо ...

Круто то, что каждый раз, когда вы вносите изменения в MEDIA, вы можете сделать это:

cd /path/to/PROJECT2/MEDIA
git pull
cd ..
git add MEDIA
git commit -m "Upgraded media to version XYZ"

Это только что зафиксировало тот факт, что подмодуль MEDIA WITHIN PROJECT2 теперь находится в версии XYZ.

Это дает вам 100% контроль над тем, какую версию MEDIA использует каждый проект. Подмодули git хороши , но вам нужно экспериментировать и узнавать о них.

С большой силой приходит великий шанс быть укушенным в попу.

gahooa
источник
Этот рабочий процесс напоминает мне об использовании частного модуля NPM stackoverflow.com/questions/7575627/…
cyrf
Если вы предпочитаете, чтобы по умолчанию использовалась последняя версия, вы можете добавить сценарий для распространения фиксации MEDIA на все зависимые проекты.
jiggunjer
3
Как это интегрируется с GitHub?
theonlygusti
27

Подумайте об использовании поддерева вместо подмодулей, это сделает вашу жизнь пользователей репо намного проще. Вы можете найти более подробное руководство в книге Pro Git .

Руслан Кабалин
источник
6
Вот еще одна информативная статья о поддереве и субмодуле: blogs.atlassian.com/2013/05/…
Бенни Нойгебауэр,
3
Согласно этой статье, один из недостатков:> Ответственность за не смешивание кода super и sub-project в коммитах лежит на вас. Никто не получил время для этого (IMO)
Роберт Дандон
20

Если я хорошо понимаю вашу проблему, вам нужны следующие вещи:

  1. Храните ваши медиа-файлы в одном репозитории git, который используется многими проектами
  2. Если вы изменяете медиа-файл в любом из проектов на вашем локальном компьютере, он должен немедленно появиться в любом другом проекте (так что вы не хотите все время фиксировать + push + pull)

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

Сначала вы должны решить одну важную вещь: хотите ли вы хранить для каждой версии в вашем репозитории проекта ссылку на версию медиа-файлов? Так, например, если у вас есть проект с именем example.com, вам нужно знать, какой style.css он использовал 2 недели назад, или последний всегда (или в основном) лучший?

Если вам не нужно это знать, решение легко:

  1. создайте репозиторий для медиа-файлов и по одному для каждого проекта
  2. создайте в своих проектах символическую ссылку, указывающую на локально клонированный медиа-репозиторий. Вы можете либо создать относительную символическую ссылку (например, ../media) и предположить, что все извлекут проект, чтобы каталог мультимедиа находился в том же месте, либо записать имя символической ссылки в .gitignore, и каждый может решить где он / она помещает медиа файлы.

Однако в большинстве случаев вам нужна эта информация о версиях. В этом случае у вас есть два варианта:

  1. Храните каждый проект в одном большом хранилище. Преимущество этого решения заключается в том, что у вас будет только 1 копия хранилища мультимедиа. Большой недостаток заключается в том, что переключаться между версиями проекта гораздо сложнее (если вы переходите на другую версию, вы всегда будете изменять ВСЕ проекты).

  2. Используйте субмодули (как объяснено в ответе 1). Таким образом, вы будете хранить медиа-файлы в одном репозитории, и проекты будут содержать только ссылку на конкретную версию медиа-репо. Но таким образом у вас обычно будет много локальных копий хранилища мультимедиа, и вы не сможете легко изменить медиафайл во всех проектах.

На вашем месте я бы, вероятно, выбрал первое или третье решение (символические ссылки или подмодули). Если вы решите использовать подмодули, вы все равно сможете сделать многое, чтобы облегчить себе жизнь:

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

  2. Вы можете добавить одну из своих копий хранилища мультимедиа в качестве удаленного хранилища для всех своих проектов.

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

cd /my/project2/media
git remote add project1 /my/project1/media

Если вы измените файл в / my / project1 / media, вы можете зафиксировать его и извлечь из / my / project2 / media, не отправляя его на удаленный сервер:

cd /my/project1/media
git commit -a -m "message"
cd /my/project2/media
git pull project1 master

Вы можете удалить эти коммиты позже (с помощью git reset), потому что вы не поделились ими с другими пользователями.

gyim
источник
1
для веб-проектов, в которых вы работаете из wwwпапки Apache , вы должны поместить .htaccessфайл в корень wwwпапки или проекта, Options +FollowSymLinksв котором он находится, или еще лучше <IfModule mod_rewrite.c>{new line}Options +FollowSymLinks{new line}RewriteEngine on{new line}</IfModule> (заменить {new line}на новую строку`)
3

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

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

Здесь есть полное руководство: http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/

Но в основном вам просто нужно связать два пути в командной строке с повышенными правами. Убедитесь, что вы используете префикс жесткой ссылки / J. Что-то вроде этого: mklink / JC: \ projects \ MainProject \ plugins C: \ projects \ SomePlugin

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

Пример: mklink / J. \ Assets \ TaqtileTools .. \ TaqtileHoloTools

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

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

ickydime
источник