Git中与ClearCase中只读组件相当的是什么？

Question

我的公司正在将版本控制工具从 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，我们认为子模块可能是最接近正确答案的东西。 但是，在拉取/重新基于存储库时，似乎需要一个额外的步骤来更新子模块代码。 理想情况下，我们希望是透明的。 而且，我们并不一定关心从父存储库的视角了解子模块中发生了什么变化，我们只关心整个子模块的某个时间点。

- jstricker

Answer 1

首先，确保理解ClearCase中(UCM类似的)配置和git之间的区别(请参见"Flexible vs static branching (GIT vs Clearcase/Accurev)")。
在查看ClearCase和Git之间的差异时，每个UCM组件必须在Git中表示为一个仓库。

如果修改了子模块，则需要进行额外的步骤，如"true nature of submodules"所述。
但是它们记录了特定的SHA1，在拉取每个'APP'时这是您想要的内容。
gitslave将允许您将Tools与'Appx'更紧密地链接在一起，但我不认为它适合您的情况。

请注意，使用子模块会：

• 将 'Tools' 设为 'APPx' 的子目录
• 使其可修改。
  Git 中没有“只读”组件：如果您可以访问存储库，则可以推送/拉取。
  如果您确实需要强制执行只读访问权限，则需要添加一个额外的“授权层”，称为gitolite。

- VonC