17

我们有两个独立的 rails_appfoo/和bar/（分开是有充分理由的）。它们都依赖于文件夹中的某些模型等，当前与和common/平行。foobar

我们当前的 svn 设置用于svn:externals共享common/. 这个周末我们想试试 git。经过大量研究，似乎解决此问题的“犹太洁食”方法是使用git submodule. 我们在将foo,分离到单独的存储库后得到了它的工作bar，common但随后实现了所有附加的字符串：

  1. 始终在提交父模块之前提交子模块。
  2. 总是在推送父模块之前推送子模块。
  3. 在提交之前确保子模块的 HEAD 指向一个分支。（如果您是 bash 用户，我建议使用 git-completion 将当前分支名称放在提示符中。）
  4. 在切换分支或拉取更改后始终运行“git submodule update”。

所有这些陷阱比add, commit,更复杂push。我们正在寻找common在 git 中共享的更简单方法。这家伙似乎在使用git subtree扩展方面取得了成功，但这与标准 git 有所不同，而且看起来仍然没有那么简单。

考虑到我们的项目结构，这是我们能做的最好的吗？我对 Rails 插件/引擎知之甚少，但这似乎是一种可能的 RoR 式共享库的方式。

提前致谢。

4

7 回答 7

8

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

所以我认为即使子模块有点复杂，也值得使用子模块。Git 1.7 在这方面有一些重大改进，例如git status现在指示子模块中未提交的修改，所以你可能不会忘记先提交子模块。一个好的 GUI 也可能会有所帮助（我有一个关于此的小型宠物项目，请参见此处）。

如果您真的不想关心子模块版本（您永远不会在公共代码中进行向后不兼容的更改），那么我还建议使用符号链接。虽然提交和获取不会比子模块容易得多......

于 2010-05-29T10:35:39.853 回答
6

我倾向于更喜欢子模块的符号链接。

1)在 3 个单独的存储库中具有foo、bar和公共代码 ( )。common

2) 在 for 的目录中，在必要时foo添加指向 的符号链接。common

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

3）检查链接。

$ git add lib/common
$ git提交

4) 重复bar

这利用了 git 尊重符号链接并存储目标位置的事实（而不是跟随链接。）

当然，期望您始终使用相同的目标路径common。我通过不签入符号链接来解决这个问题，并在我的每个项目中添加一个 README.setup 文件，提醒我在初始化时添加必要的符号链接。devsetup.sh进行这种初始化的a在这里也很有用。

IMO，这比子模块要好得多。

于 2010-04-20T06:06:49.720 回答
5

插件是完全可行的方法，如果您最终在两个以上的项目中使用它或者对公众有用，那么可能值得努力使其成为宝石。

这是关于这个主题的一个很好的资源

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，一个用于plugin。

然后在每个项目中保持最新数据，您将能够做到

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

使其保持最新状态。

祝你好运！

——乔纳森

于 2010-04-19T21:08:43.307 回答
2

Git 子树是自 1.7.11 以来 GIT 的一部分，我写了一篇关于在 Rails 应用程序之间共享代码的文章：http: //igor-alexandrov.github.com/blog/2013/03/28/using-git-subtree-to -share-code-between-rails-applications

简而言之：是的 git-subtree 工作得很好！

于 2013-03-28T12:07:44.093 回答
1

如果您正在考虑制作插件，您还应该考虑制作 gem。它们在使用方面非常相似，但 gems 往往更易于使用，支持依赖管理，并且更易于与社区共享/分发。

Railscast 的 Ryan Bates 有一个很棒的关于制作 gem 的教程视频，你可以在这里找到：http ://railscasts.com/episodes/135-making-a-gem

于 2010-06-19T21:35:43.663 回答
0

您可以做的最好的事情是为您的公共库甚至是 gem 创建一个插件，这样您就有一种很好的方式来更新/分发它。

于 2010-06-19T11:02:00.163 回答
0

您可以使用公共代码创建一个存储库并将其克隆两次。两个克隆都会变成 foo 和 bar。您仍然可以在两个项目的单独分支中开发公共代码，并将该分支推送到公共代码存储库。要更新项目中的公共代码，您只需将公共分支合并到 foo 和 bar 的主分支中。

更新：您可以将其想象为具有三个分支的单个存储库：common、foo 和 bar。您将在公共分支中拥有公共代码，并将项目特定代码仅添加到 foo 或 bar 分支。现在，您可以将此存储库克隆两次，分别为 foo 和 bar，并从它们中删除一个分支（从 bar 存储库中删除分支 foo，从 foo 存储库中删除分支 bar）。然后，您将从第一个存储库中删除 foo 和 bar。这将成为通用存储库。最终结果将与上述相同。

于 2010-04-19T19:16:12.297 回答