我的公司正在将版本控制工具从 Rational ClearCase 转换到 Git。我们有以下开发场景,我们想知道在 Git 中是否有适当的模式可以遵循以实现我们在 ClearCase 中拥有的相同行为。
以下是我们情况的一些基本要点:
我们有许多独立应用程序。 让我们称这些为 AppA、AppB 和 AppC。
我们还有某些文件(构建脚本等)对所有项目都是通用的。 让我们称之为 Tools。
对于任何给定的 AppA、AppB 或 AppC 代码版本,我们需要一个特定版本的 Tools 代码。
我们的大多数开发人员从不修改 Tools 代码。
对于 ClearCase,我们的模型如下所示:
组件:app_a、app_b、app_c、tools
项目:AppA、AppB、AppC、Tools
项目 AppA 包括 app_a 作为读/写组件和 tools 作为只读组件。
项目 AppB 包括 app_b 作为读/写组件和 tools 作为只读组件。
项目 AppC 包括 app_c 作为读/写组件和 tools 作为只读组件。
项目 Tools 包括 tools 作为读/写组件。
每个 App* 项目的基线引用了 app_* 和 tools 组件上的基线。 当开发人员重新基于推荐的基线时,他们会从两个组件中拉取更改。
对于 Git,我们认为子模块可能是最接近正确答案的东西。 但是,在拉取/重新基于存储库时,似乎需要一个额外的步骤来更新子模块代码。 理想情况下,我们希望是透明的。 而且,我们并不一定关心从父存储库的视角了解子模块中发生了什么变化,我们只关心整个子模块的某个时间点。
以下是我们情况的一些基本要点:
我们有许多独立应用程序。 让我们称这些为 AppA、AppB 和 AppC。
我们还有某些文件(构建脚本等)对所有项目都是通用的。 让我们称之为 Tools。
对于任何给定的 AppA、AppB 或 AppC 代码版本,我们需要一个特定版本的 Tools 代码。
我们的大多数开发人员从不修改 Tools 代码。
对于 ClearCase,我们的模型如下所示:
组件:app_a、app_b、app_c、tools
项目:AppA、AppB、AppC、Tools
项目 AppA 包括 app_a 作为读/写组件和 tools 作为只读组件。
项目 AppB 包括 app_b 作为读/写组件和 tools 作为只读组件。
项目 AppC 包括 app_c 作为读/写组件和 tools 作为只读组件。
项目 Tools 包括 tools 作为读/写组件。
每个 App* 项目的基线引用了 app_* 和 tools 组件上的基线。 当开发人员重新基于推荐的基线时,他们会从两个组件中拉取更改。
对于 Git,我们认为子模块可能是最接近正确答案的东西。 但是,在拉取/重新基于存储库时,似乎需要一个额外的步骤来更新子模块代码。 理想情况下,我们希望是透明的。 而且,我们并不一定关心从父存储库的视角了解子模块中发生了什么变化,我们只关心整个子模块的某个时间点。