Совместное использование кода между двумя или более приложениями rails ... альтернативы подмодулям git?

Question

У нас есть два отдельных rails_app, foo/ и bar/ (отдельные по уважительной причине). Они оба зависят от некоторых моделей и т. Д. В папке common/, в настоящее время параллельно foo и bar.

Наша текущая настройка SVN использует svn:externals, чтобы поделиться common/. В эти выходные мы хотели попробовать Git. После долгих исследований выясняется, что «кошерный» способ решить эту проблему - использовать git submodule. Мы получили эту работу после разделения foo, bar, common на отдельные репозитории, но затем реализовали все присоединенные строки :

1. Всегда передайте подмодуль перед тем, как совершить родительский.
2. Всегда нажимайте на подмодуль, прежде чем нажимать на родителя.
3. Убедитесь, что заголовок подмодуля указывает на ветку, прежде чем совершать ее. (Если вы пользователь bash, я рекомендую использовать git-complete, чтобы вставить текущее имя ветки в ваше приглашение.)
4. Всегда запускать 'git submodule update' после переключения веток или получения изменений.

Все эти затруднения еще более усложняют, чем add, commit, push. Мы ищем более простые способы поделиться common в git. Этот парень , похоже, добился успеха, используя расширение git subtree, но это отличается от стандартного gitand, но выглядит не так просто.

Это лучшее, что мы можем сделать, учитывая структуру нашего проекта? Я не знаю достаточно о плагинах / движках rails, но это похоже на возможный RoR-способ совместного использования библиотек.

Заранее спасибо.

Answer 1

Я думаю, что система подмодулей git имеет большое преимущество перед svn: внешними или символическими ссылками (и это также делает их более сложными в использовании): фактическая версия подмодуля сохраняется для каждой версии суперпроекта. Поэтому довольно безопасно вносить изменения в подмодуль, который нарушает обратную совместимость: можно будет извлечь любую версию суперпроекта (ов) с правильной версией подмодуля, потому что суперпроект будет содержать ссылку на надлежащий код подмодуля. Вы также можете поддерживать две ветви подмодуля (например, v1.0.x и v2.0.x) и без проблем использовать разные ветви в разных проектах.

Так что я думаю, что стоит использовать подмодули, даже если они немного сложны. В Git 1.7 есть несколько существенных улучшений в этой области, например, git status теперь указывает на незафиксированные изменения в подмодулях, так что вы, вероятно, не забудьте сначала зафиксировать подмодули. Хороший графический интерфейс также может помочь (у меня есть небольшой проект для домашних животных, см. здесь ).

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

Answer 2

Я предпочитаю символические ссылки для субмодулей.

1) Имеют foo, bar и общий код (common) в 3 отдельных репозиториях.

2) В каталоге для foo добавьте символическую ссылку на common, где это необходимо.

$ cd foo
$ ln -s /path/to/common lib/common

3) Проверьте по ссылке.

$ git add lib/common
$ git commit

4) Повторите для bar

Это использует тот факт, что git уважает символические ссылки и сохраняет местоположение цели (в отличие от перехода по ссылке).

Конечно, вы ожидаете, что вы последовательно будете использовать один и тот же целевой путь для common. Я работаю в обход этого, не проверяя символическую ссылку и добавляя файл README.setup в каждый из моих проектов, напоминая мне о необходимости добавления необходимых символических ссылок при инициализации. Наличие devsetup.sh, которое выполняет такую ​​инициализацию, также полезно здесь.

ИМО, с этим гораздо приятнее, чем с подмодулями.

Answer 3

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

Вот хороший ресурс по теме

http://nubyonrails.com/articles/the-complete-guide-to-rails-plugins-part-i

и что еще важнее ...

http://nubyonrails.com/articles/the-complete-guide-to-rails-plugins-part-ii

В итоге у вас будет три git-репозитория: один для foo , один для bar и один для плагина .

Затем в каждом проекте, чтобы держать его в курсе данных, вы сможете сделать

./script/plugin install --force git://github.com/path/to/plugin/repository

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

Удачи!

- Джонатан

Answer 4

Git поддерево является частью GIT с 1.7.11, и я написал статью о совместном использовании кода между приложениями Rails: http://igor -alexandrov.github.com / blog / 2013/03/28 / using-git -subtree к доле-кода между рельсами-приложением

Вкратце: да, git-subtree работает и прекрасно работает!

Answer 5

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

У Райана Бейтса из Railscast есть отличное обучающее видео о создании драгоценного камня, которое вы можете найти здесь: http://railscasts.com/episodes/135-making-a-gem

Answer 6

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

Answer 7

Вы можете создать репозиторий с общим кодом и дважды его клонировать. Оба клона станут foo и bar. Вы все еще можете разработать общий код в отдельных ветках в обоих проектах и ​​перенести эту ветку в общий репозиторий кода. Чтобы обновить общий код в проектах, вам нужно просто объединить общую ветку с основными ветками foo и bar.

ОБНОВЛЕНИЕ: Вы можете представить это как один репозиторий с тремя ветвями: common, foo и bar. У вас будет общий код в общей ветке и вы добавите специальный код проекта только в ветки foo или bar. Теперь вы можете дважды клонировать этот репозиторий как foo и bar и удалить одну ветку из них обоих (ветку foo из репозитория bar и ветку bar из репозитория foo). Затем вы удалили бы и foo, и bar из первого репозитория. Это станет общим хранилищем. Окончательный результат будет таким же, как указано выше.