Проекты в рамках проектов с использованием Git

Question

Как настроить проект Git, содержащий другие проекты?

например. Я работаю над онлайн-картографическим приложением. Мы разработали инструмент GPS вместе с оборудованием в SF. Мы одновременно разработали скрипт Python Geomapping вместе с другой задачей (которая заботится только о геомаппинге). Наши собственные файлы ядра объединяют их и основываются на них для нужного нам приложения.

Каждый из проектов должен существовать сам по себе - люди, которые заинтересованы в GPS, заинтересованы только в GPS - но «родительский» проект, который включает в себя все остальные, должен быть доступен как проект.

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

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

Это выполнимо с Git? С ртутью? Имеет ли значение хост (GitHub, Gitorious)?

У меня есть идея использовать Subversion для «родителя» - игнорировать папки .git и использовать Git для проектов (игнорируя папки .svn) - но это только последнее средство.

редактирование:

Чтобы объяснить, почему я не хочу субмодулей:

1. Когда пользователи загружают, zip не включает подмодули ( здесь & здесь ). То же самое, когда даже соавторы пытаются настроить проект. Это шоу-стоппер.
2. Подмодули заморожены - они не (легко) выбирают последнюю версию проекта, на которую указывают.
3. Другие причины, указанные в фантастических ответах ниже и в этом монологе в NoPugs .

Слияние поддеревьев (представленное мне Полом ниже) не подойдет: трудно обновить источник [поддерева] из проекта, в который он сливается, и этот источник должен находиться вне корневого каталога. папка проекта. Будучи веб-приложением, очень важно, чтобы все мои страницы имели внутреннюю ссылку на папку внутри них, а тестирование и обновления выполнялись непосредственно в этой папке. (Надеюсь, это понятно и полезно для других.)

Все еще изучаю настройку «удаленных веток», но другие идеи все еще приветствуются.

Answer 1

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

Существует две возможности сохранить подпроекты в качестве независимых репозиториев git, которые вы извлекаете из основного (интеграционного) репо:

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

• Настройте каждый проект в качестве удаленной ветви в своем основном репо и объедините каждый из них в свою master (интеграционную) ветку, которая также содержит ваши основные файлы. Это требует некоторой дисциплины: если вы вносите какие-либо изменения во внешние проекты в своем основном репо, они должны быть внесены в ветку, а затем объединены с мастером; и вы никогда не хотите сливаться с ветками проекта. Это облегчает отправку изменений обратно во внешние проекты и является совершенно приемлемым использованием веток в Git.

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

Если вы попытаетесь запустить SVN & Git в одном и том же каталоге, вы сильно затрудните использование ветвления в любой системе, потому что SVN выполняет ветвление, копируя каталоги файлов, пока Git отслеживает указатели. Ни одна из систем не будет автоматически видеть ветви, которые вы создаете в другой. Я думаю, что «решение» - это больше проблем, чем оно того стоит.

Answer 2

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

Я использовал git-submodule и git-svn, и он работал достаточно хорошо. Минусы были:

1. Для того, чтобы идти в ногу с хранилищем библиотеки, мне пришлось выполнить новый коммит, чтобы обновить подмодуль git hash «pointer». Это связано с тем, что подмодули git, в отличие от svn: externals, прикрепляются к определенному идентификатору коммита. Это не может быть реальным недостатком, если вы действительно хотите закрепить стабильную версию, я работал с кодом, который был WIP.

2. Первоначальное использование git-репо с субмодулями требует дополнительного шага с помощью «git submodule init». Это не проблема для вас, но для других, использующих ваш код, им придется запомнить или попросить выполнить этот шаг перед компиляцией / выполнением / тестированием вашего кода.

3. Если вы используете командную строку, легко испортить ваш репозиторий с помощью git-add. Это потому, что вы набираете git add subm<tab> для завершения до git add submodule, но оно автоматически завершается до git add submodule/ - обратите внимание на завершающий слеш. Если вы выполняете команду с завершающей косой чертой, то она подмывает подмодуль и вместо этого добавляет все содержащиеся в нем файлы. Этого можно избежать, используя git-gui, git add . или просто тренируя себя, чтобы удалить косую черту (это случалось со мной достаточно раз, когда я тренировал себя для ее удаления)

4. Коммиты субмодулей могут испортить git rebase -i. Я забыл точные детали, но это особенно плохо, если у вас есть «грязный» подмодуль и вы запускаете rebase-интерактив. Обычно с грязным деревом вы не можете перебазировать, но подмодули не проверяются. Наличие нескольких подмодульных коммитов в группе ребаз также вызывает проблемы. Последний хеш подмодуля фиксируется для первого выбора в вашем списке, и это довольно сложно исправить позже. Это можно обойти с помощью более тщательного рабочего процесса (т. Е. Тщательно решить, когда выполнять коммиты подмодуля ...), но это может быть PITA.

Шаги по настройке были примерно такими:

1. Пробег git svn clone https://project.svn.sourceforge.net/svnroot/project/project/trunk
2. Выдвиньте это как "настоящий" проект git, например. GitHub
3. Теперь в вашем собственном git-репозитории запустите git submodule init
4. git submodule add git://github.com/project subproject
5. На этот раз тоже сделайте это с вашим собственным репо.

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

Каждый раз, когда вам нужно обновить код геомапинга, вы запускаете что-то вроде:

cd subproject
git svn rebase
git svn push  # this updates the git mirror of the subproject
cd ..
git add subproject # careful with the trailing slash!
git commit -m "update subproject"
git push # this pushes the commit that updates the subproject

Я не видел много учебников по рабочему процессу подмодуля git, поэтому я надеюсь, что это поможет вам принять решение.

Answer 3

Из того небольшого, что я прочитал о Externals , похоже, это порт SVN 'externals' для GIT.

Это решает некоторые проблемы с подмодулями GIT, включая автоматическое обновление до последней версии.

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

В качестве альтернативы, следующее программное обеспечение (похоже, его можно использовать с GitHub). Может быть, это еще один способ снять кожу с кошки: Коса ( Страница Softpedia )

Answer 4

git-submodule может быть тем, что вы ищете:

http://book.git -scm.com / 5_submodules.html

http://git -scm.org / gitwiki / GitSubmoduleTutorial

Answer 5

Это зависит от того, над каким проектом вы работаете, и какие инструменты, если таковые имеются, должны взаимодействовать с вашим SCM. Например, Rails часто использует Capistrano для развертывания, и Capistrano делает определенные предположения о том, как будет выглядеть ваша структура каталогов относительно корня вашего хранилища. В этом случае, если у вас есть несколько взаимосвязанных приложений rails, вам нужно использовать субмодули. Каждое приложение получает свой собственный репозиторий, а затем у вас есть большой репозиторий, который управляет каждым из независимых репозиториев как подмодулями.

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

Извлечение некоторого подраздела репозитория в качестве отдельного объекта при ведении истории версий сложно в git, и поэтому неплохо планировать заранее.

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