【问题标题】:git submodules: customizationgit 子模块:自定义
【发布时间】:2009-06-25 11:00:46
【问题描述】:

使用 git 子模块时,进行自定义的首选方式是什么?我应该...

  • 分叉项目并跟踪分叉
  • 尝试覆盖默认行为
  • 在本地进行更改

如果这些都没有意义,那还有什么意义呢?

【问题讨论】:

  • 如果您能阐明“覆盖默认行为”和“在本地进行更改”的含义,将会有所帮助。我不太确定你在说什么。

标签: git customization dvcs git-submodules


【解决方案1】:

我不太确定您的问题是否暗示您想要包含的所有项目都已经是 git 项目,或者它们当前是否是 svn、mercurial、非版本控制的。如果是后者,则必须逐案回答。

您想要包含和自定义的项目很可能已经在 github 上,那么您绝对应该通过 github 分叉并将这些分叉用作子模块。任何自定义都应该签入并推送到 github。

如果您想要包含的项目在其他地方(或基于 svn、mercurial 等),则可能会更棘手。一种方法是在本地 fork 项目,然后设置 cron-jobs 将任何传入的更改推送到 github。即创建github镜像。要完全控制合并和升级,您可能必须分叉这些镜像并将这些分叉作为子模块包含在您的项目中,检查本地自定义并将它们推送到镜像的分支。

替代方案 #3,派生项目并仅进行本地签入,可用于您没有上述选项并且您创建的内容并非真正旨在轻松分发的情况。

Monkey 修补(您的列表中的第二个替代方案)应该是您不希望项目依赖于您保持自定义分支与上游更改保持同步的情况的替代方案。

【讨论】:

    【解决方案2】:

    我发现使用 git submodule 分叉子项目非常烦人,这就是我改写git subtree 的原因。

    git subtree 的想法是您将子项目的内容导入到您自己的项目中,因此您可以一次分支所有内容并根据需要进行新的提交。然后,当您准备好时(如果有的话),您可以使用git subtree split 提取子项目的历史并将其提交到上游。

    【讨论】:

      猜你喜欢
      • 2014-09-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-12-06
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-09-22
      相关资源
      最近更新 更多