У меня есть приложение Rails, которое на самом деле не является «общедоступным» приложением, но я все же хотел бы поместить его в публичный репозиторий git (hub). Зачем? Ну, главным образом потому, что я на самом деле хочу поделиться кодом с другими заинтересованными людьми, работающими в моей области. Бесплатное репозиторий на github не помешает, но если бы я на самом деле не хотел делиться кодом, я бы просто заплатил за него, конечно.
базовый контекст
Таким образом, проблема заключается в том, чтобы скрыть «личные» данные от git-репо. Каковы частные детали? Ну, Rails довольно хорошо их изолирует. Иногда это отдельные файлы, такие как ./config/database.yml, или несколько других специфичных для приложения (не по умолчанию Rails) ./config/x файлов. В других случаях, к сожалению, могут быть отдельные строки в файлах, которые могут быть использованы совместно, но не уверены в этом.
Сейчас я спрашиваю: НЕ на самом деле помогает найти все «частные» места в приложении Rails3. Нет, это был просто некоторый контекст для основной проблемы.
простой способ управления личными вещами
То, что я на самом деле прошу, это предложить использовать для механизмов , чтобы сохранить личные вещи «где-то еще» и объединить их в приложение, извлеченное из публичного репозитория git.
Я знаю, что основная идея такова: «Ну, оставь их где-нибудь еще, на свое усмотрение, а затем скопируй их». Но да, где? (еще один частный репозиторий git? Общая файловая система?), и как управлять «копированием»? ruby / rails люди любят автоматизировать вещи и автоматизировать лучшие практики, я думаю, что для этого должен быть инструмент, или, по крайней мере, кто-то, у кого есть предложения для лучших практик?
что я хочу
Это должно быть очень просто . Настолько просто, что я могу оставить инструкции для гипотетически едва компетентных коллег, охватывающих развертывание приложения (объединение публичного репо с частными данными), а также изменение / добавление / фиксация «личных данных».
Он должен охватывать целые файлы «приватных данных», а в идеале также отдельные строки в других публичных файлах, хотя может не быть необходимым, но идеальным инструментом / процесс сделает это.
Приложение будет развернуто / извлечено / настроено на нескольких хостах, и его должно быть легко проверить на совершенно новом хосте без каких-либо специальных настроек на этом хосте. Аналогично, с любым хост-аккаунтом. То же самое, что и обычный git checkout, не проблема в этих обстоятельствах, верно?
создание снимков / управление зависимостями. Вот тот, который, возможно, придется пожертвовать, но это было бы хорошо. частный конфиг иногда меняется, верно? При обычной настройке «одного git-репо» ваши личные данные снимаются и управляются вместе со всем остальным кодом. Довольно просто увидеть, какая версия конфигурации «приватных данных» подходит к какой версии остального кода, потому что она просто автоматическая - вы делаете git checkout для определенного снимка и получаете, ну, в общем, состояние всех код, включая личные данные в этом снимке. Было бы неплохо сохранить эту функцию с планом «частные данные в отдельном месте», так что все еще можно узнать, какая версия личных данных идет именно с тем, что делает git snapshot .... но это может быть неосуществимо.
** Это требование сначала заставило меня задуматься о «о, просто используйте подмодули git, личные данные в частном git-репо, публичные ссылки на git-репо с подмодулем git». Это сработало бы, если бы «приватные данные» представляли собой один каталог (весь этот каталог и только этот каталог), но я не уверен, что это относится к приложению Rails. В идеале некоторые из ./config могут быть разделены, а личные данные могут находиться где-то еще. Но я полагаю, что одним из вариантов будет просто убедиться, что все личные данные находятся в «config», и сохранить ВСЕ из config «private», даже если вам это не нужно. Не идеально, если есть лучшее решение, но я полагаю, что это один из подходов.
Так
Есть идеи? Существуют ли инструменты, которые уже существуют для этого? Это хорошо? Или, если не инструменты, предложения относительно подходов или лучших практик? (Если бы я мог найти убийственный способ сделать это, который изящен и силен, я мог бы, возможно, написать инструмент, чтобы автоматизировать это. Прямо сейчас, я все еще даже не уверен относительно того, каков «правильный» способ сделать это. )