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

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

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

  • Всегда завершайте подмодуль перед выполнением родительского элемента.
  • Всегда подталкивайте подмодуль, прежде чем нажимать родителя.
  • Убедитесь, что подмодуль HEAD указывает на ветвь, прежде чем совершать ее. (Если вы являетесь пользователем bash, я рекомендую использовать git -completion для размещения текущего имени ветки в приглашении.)
  • Всегда запускайте обновление подмодуля git после переключения ветвей или вытягивания изменений.

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

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

Спасибо заранее.

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

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, который выполняет эту инициализацию.

IMO, это гораздо приятнее, чем подмодули.

Ответ 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, один для бара и один для плагина.

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

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

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

Удачи!

- jonathan

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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