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

Как настроить проект Git для других проектов?

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

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

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

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

Это можно сделать с помощью Git? С Mercurial? Учитывается ли хозяин (GitHub, Gitorious)?

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

изменить:

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Есть две возможности, которые поддерживают подпроекты как независимые репозитории git, которые вы извлекаете из основного (интеграционного) репо:

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

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

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

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

Ответ 2

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

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

  • Чтобы быть в курсе репозитория библиотеки, мне пришлось выполнить новую фиксацию, чтобы обновить указатель субмодуля git hash ". Это связано с тем, что подмодули git, в отличие от svn: externals, привязаны к определенному идентификатору фиксации. Это не может быть фактическим недостатком, если вы действительно хотите привязать стабильную версию, я работал с кодом, который был WIP.

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

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

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

Действия по настройке были следующими:

  • Запустить git svn clone https://project.svn.sourceforge.net/svnroot/project/project/trunk
  • Нажмите это как "реальный" проект git, например. GitHub
  • Теперь в своем собственном репозитории git запустите git submodule init
  • git submodule add git://github.com/project subproject
  • На этот раз нажмите и на свое собственное репо.

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

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

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, поэтому, надеюсь, это поможет вам решить.

Ответ 4

Из небольшого числа, которое я прочитал о Externals, он выглядит как порт внешних внешних элементов SVN на GIT,

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

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

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

Ответ 5

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

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

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

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