5

我的公司正在将我们的版本控制工具从 Rational ClearCase 更改为 Git。我们有以下开发场景，我们很好奇 Git 是否可以遵循适当的模式来实现我们在 ClearCase 中的相同行为。

以下是关于我们情况的一些基本要点：

  1. 我们有许多离散的应用程序。我们将它们称为 AppA、AppB 和 AppC。
  2. 我们还有所有项目通用的某些文件（构建脚本等）。我们称之为工具。
  3. 对于 AppA、AppB 或 AppC 代码的任何给定剪切，我们需要工具代码的特定剪切。
  4. 我们的大多数开发人员从不修改工具代码。

对于 ClearCase，我们这样建模：

组件：app_a、app_b、app_c、工具

项目：AppA、AppB、AppC、工具

项目 AppA 包括 app_a 作为读/写组件和工具作为只读组件。

项目 AppB 包括 app_b 作为读/写组件和工具作为只读组件。

Project AppC 包括 app_c 作为读/写组件和工具作为只读组件。

项目工具包括作为读/写组件的工具。

App* 项目的每个基线都引用了 app_* 和工具组件的基线。当开发人员重新设置为推荐的基线时，他们会从两个组件中提取更改。

对于 Git，我们认为子模块可能是最接近正确答案的东西。但是，在拉取/重新定位存储库时，听起来需要一个额外的步骤来更新子模块代码。理想情况下，我们希望是透明的。此外，我们不一定关心从父存储库的角度知道子模块中发生了什么变化；我们只关心整个子模块的一个时间点。

4

1 回答 1

4

首先，一定要了解 ClearCase 中的（类 UCM）配置和 git 之间的区别（请参阅“灵活与静态分支（GIT 与 Clearcase/Accurev） ”）。
查看ClearCase 和 Git 之间的差异时，每个 UCM 组件都必须在 Git 中表示为存储库。

如果修改子模块，则需要额外的步骤，如“子模块的真实性质”中所述。
但是他们记录了一个特定的 SHA1，这是你在拉每个“ APP”时想要的。
gitslave将允许您与 ' ' 保持Tools更紧密的联系Appx，但我认为它不适合您的情况。

请注意，使用子模块将：

  • 使 ' ' 成为 ' 'Tools的子目录APPx
  • 使其可修改。
    git 没有“只读”组件：如果您可以访问存储库，则可以推/拉。
    如果您确实需要强制执行读取访问，那么您需要添加一个额外的“授权层”，称为gitolite。
于 2012-06-22T21:44:09.700 回答