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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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