Совместное использование кода между двумя или больше приложениями для направляющих … альтернативы подмодулям мерзавца?
У нас есть два отдельных rails_app, foo/ и bar/ (отдельный на серьезном основании). Они оба зависят от некоторых моделей, и т.д. в a common/ папка, в настоящее время находите что-либо подобное к foo и bar.
Наши текущие svn устанавливают использование svn:externals совместно использовать common/. В эти выходные мы хотели испытать мерзавца. После большого исследования кажется, что "кошерный" способ решить это использует git submodule. Мы получили ту работу после разделения foo,bar,common в отдельные репозитории, но затем реализованный все строки присоединили:
- Всегда фиксируйте подмодуль прежде, чем фиксировать родителя.
- Всегда продвигайте подмодуль прежде, чем продвинуть родителя.
- Удостоверьтесь, что ГОЛОВА подмодуля указывает на ответвление перед согласием на него. (Если Вы - пользователь удара, я рекомендую использовать завершение мерзавца, чтобы поставить текущее имя ответвления в Вашей подсказке.)
- Всегда выполняемый 'подмодуль мерзавца обновляет' после переключения ответвлений или получения по запросу изменений.
Все эти глюки усложняют вещи далее, чем add,commit,push. Мы ищем более простые способы совместно использовать common в мерзавце. Этот парень, кажется, имеет успех с помощью git subtree расширение, но это отклоняется от стандарта gitand, все еще не выглядит что простым.
Действительно ли это является лучшим, мы можем сделать, учитывая нашу структуру проекта? Я не знаю достаточно о плагинах/механизмах направляющих, но это походит на возможный RoR-выход способ совместно использовать библиотеки.
Заранее спасибо.
6 ответов
Я думаю, что система подмодулей git имеет большое преимущество перед svn: externals или символическими ссылками (и это также затрудняет их использование): актуальная версия подмодуля сохраняется для каждой версии суперпроекта. Таким образом, вполне безопасно вносить изменения в подмодуль, нарушающий обратную совместимость: можно будет проверить любую версию суперпроекта (ов) с соответствующей версией подмодуля, потому что суперпроект будет содержать ссылку на правильный код подмодуля. Вы также можете поддерживать две ветви подмодуля (например, v1.0.x и v2.0.x) и без проблем использовать разные ветви в разных проектах.
Поэтому я думаю, что действительно стоит использовать подмодули, даже если они немного сложны. Git 1.7 имеет несколько серьезных улучшений в этой области, например git status теперь указывает незафиксированные изменения в подмодулях, поэтому вы, вероятно, не забудьте сначала зафиксировать подмодули. Хороший графический интерфейс также может помочь (у меня есть небольшой проект по этому поводу, см. здесь ).
Если вы действительно не хотите заботиться о версиях подмодулей (вы никогда не вносите обратно несовместимые изменения в общий код), я также предлагаю использовать символические ссылки. Хотя фиксация и выборка не будут намного проще, чем для подмодуля ...
Плагин - это то, что вам нужно. усилия превратить его в драгоценный камень.
Вот хороший ресурс по этой теме
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
, чтобы сохранить это актуально.
Удачи!
- Джонатан
Я предпочитаю символьные ссылки субмодулям.
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 учитывает символические ссылки и сохраняет местоположение цели (в отличие от перехода по ссылке).
Конечно, ожидается, что вы должны постоянно использовать один и тот же целевой путь для общего . Я работаю над этим, не проверяя символическую ссылку и добавляя файл README.setup в каждый из моих проектов, напоминающий мне добавить необходимые символические ссылки при инициализации. Здесь также полезно иметь devsetup.sh , который выполняет такого рода инициализацию.
ИМО, с этим гораздо приятнее иметь дело, чем с подмодулями.
Вы можете создать репозиторий с общим кодом и клонируйте его дважды. Оба клона станут foo и bar. Вы по-прежнему можете разрабатывать общий код в отдельных ветвях обоих проектов и перемещать эту ветвь в общий репозиторий кода. Чтобы обновить общий код в проектах, вам нужно просто объединить общую ветвь с основными ветвями foo и bar.
ОБНОВЛЕНИЕ: Вы можете представить это как единый репозиторий с тремя ветвями: common, foo и bar. У вас будет общий код в общей ветке, а код конкретного проекта будет добавлен только в ветки foo или bar. Теперь вы можете клонировать этот репозиторий дважды, как foo и bar, и удалить одну ветку из них обоих (ветвь foo из репозитория bar и ветвь bar из репозитория foo). Затем вы удалите и foo, и bar из первого репозитория. Это станет общим хранилищем. Окончательный результат будет таким же, как указано выше.
Лучшее, что вы можете сделать, это создать плагин для ваших общих библиотек или даже gem, тогда у вас будет хороший способ обновлять/распространять его.
Если вы хотите создать плагин, вам также следует подумать о создании драгоценного камня. Они очень похожи с точки зрения их использования, но с гемами, как правило, легче работать, они поддерживают управление зависимостями и их легче делиться / распространять с сообществом.
У Райана Бейтса из Railscast есть отличный обучающий видеоролик о создании драгоценного камня, который вы можете найти здесь: http://railscasts.com/episodes/135-making-a-gem