在两个或更多rails应用程序之间共享代码... git子模块的替代品？ [英] Sharing code between two or more rails apps... alternatives to git submodules?

问题描述

我们有两个单独的rails_app， foo / 和 bar / （单独出于正当理由）。它们都依赖于某些模型等，在 common / 文件夹中，当前与 foo 和<$ c $并行我们目前的svn设置使用 svn：externals 共享。

code>公共/ 。这个周末我们想试试git。经过大量研究，似乎解决这个问题的犹太教方式是使用 git submodule 。分开 foo ， bar ， common 到单独的存储库，但后来实现了所有附加字符串：

1. 始终在提交父级之前提交子模块。


2. 推送父级。


3. 确保子模块的HEAD在提交之前指向分支。 （如果您是bash用户，我建议使用git-completion将当前分支名称放入提示符中。）


4. 切换分支或拖动更改后始终运行git submodule update 。

所有这些细节都比 add ，提交，推。我们正在寻找更简单的方式在git中共享 common 。 这家伙似乎使用 git subtree 取得成功扩展，但偏离标准gitand仍然看起来并不那么简单。

这是我们可以做的最好的给我们的项目结构吗？我对轨道插件/引擎不够了解，但这似乎是一种可能的共享库的方式。

预先感谢。

解决方案

我认为git子模块系统与svn：externals或符号链接相比具有很大优势（并且这也使得它们更难以使用）：实际的子模块版本针对每个超级项目版本进行存储。因此，在子模块中进行更改会降低向后兼容性的安全性：可以使用适当的子模块版本检出任何版本的超级项目，因为超级项目将包含对正确子模块代码的引用。您也可以维护子模块的两个分支（例如v1.0.x和v2.0.x），并在不同项目中使用不同的分支而不会出现问题。

所以我认为使用子模块真的很有价值，即使它们有点复杂。 Git 1.7在这方面有了一些重大的改进，例如 git status 现在表示子模块中未提交的修改，所以你可能不会先忘记提交子模块。一个好的图形用户界面也可能是一个帮助（我有一个关于此的小型项目，请参阅此处）。

如果你真的不想关心子模块版本（你永远不会在通用代码中做出后向不兼容的更改），那么我也建议使用符号链接。尽管提交和提取不会比子模块容易得多......

We have two separate rails_app, foo/ and bar/ (separate for good reason). They both depend on some models, etc. in a common/ folder, currently parallel to foo and bar.

Our current svn setup uses svn:externals to share common/. This weekend we wanted to try out git. After much research, it appears that the "kosher" way to solve this is using git submodule. We got that working after separating foo,bar,common into separate repositories, but then realized all the strings attached:

1. Always commit the submodule before committing the parent.
2. Always push the submodule before pushing the parent.
3. Make sure that the submodule's HEAD points to a branch before committing to it. (If you're a bash user, I recommend using git-completion to put the current branch name in your prompt.)
4. Always run 'git submodule update' after switching branches or pulling changes.

All these gotchas complicate things further than add,commit,push. We're looking for simpler ways to share common in git. This guy seems to have success using the git subtree extension, but that deviates from standard gitand still doesn't look that simple.

Is this the best we can do given our project structure? I don't know enough about rails plugins/engines, but that seems like a possible RoR-ish way to share libraries.

Thanks in advance.

解决方案

I think that the git submodule system have a great advantage over svn:externals or symbolic links (and it is also that makes them more difficult to use): the actual submodule version is stored for each superproject version. So is is quite safe to make changes in the submodule that breaks backward-compatibility: it will be possible to checkout any version of the superproject(s) with the proper submodule version, because the superproject will contain a reference to the proper submodule code. You may also maintain two branches of the submodule (v1.0.x and v2.0.x, for example) and use different branches in different projects without a problem.

So I think it is really worth to use submodules even if they are a bit complicated. Git 1.7 has some major improvements on this area, for example git status now indicates the uncommitted modifications in submodules, so you probably don't forget to commit submodules first. A good GUI may also be a help (I have a small pet project about this, see here).

If you really don't want to care about submodule versions (you never make backward-incompatibile changes in the common code) then I also suggest using symbolic links. Although committing and fetching won't be much easier than for a submodule...

这篇关于在两个或更多rails应用程序之间共享代码... git子模块的替代品？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！