我的公司正在将我们的版本控制工具从Rational ClearCase更改为Git。我们有以下开发方案，我们很好奇Git是否有适当的模式来实现我们在ClearCase中的相同行为。
以下是关于我们情况的一些基本观点：
- 我们有许多独立的应用程序。我们称之为AppA，AppB和AppC。
- 我们还拥有所有项目共有的某些文件（构建脚本等）。我们称之为工具。
- 对于AppA，AppB或AppC代码的任何给定剪切，我们需要特定的工具代码剪切。
- 我们的大多数开发人员从不修改工具代码。
对于ClearCase，我们这样建模：
组件：app_a，app_b，app_c，tools
项目：AppA，AppB，AppC，工具
Project AppA包括app_a作为读/写组件，工具作为只读组件。
Project AppB包括app_b作为读/写组件，工具作为只读组件。
Project AppC包括app_c作为读/写组件和工具作为只读组件。
项目工具包括作为读/写组件的工具。
App *项目的每个基线都引用了app_ *和工具组件的基线。当开发人员重新定义到建议的基线时，他们会从两个组件中获取更改。
对于Git，我们认为子模块可能是最接近正确答案的东西。但是，在提取/重新定位存储库时，听起来需要额外的步骤来更新子模块代码。理想情况下，我们希望透明。此外，我们不一定关心从父存储库的角度知道子模块中发生了什么变化;我们只关心整个子模块的时间点。
答案 0 :(得分：4)
首先，请务必了解ClearCase和git中的（类UCM）配置之间的区别（请参阅“Flexible vs static branching (GIT vs Clearcase/Accurev)”）。
查看differences between ClearCase and Git时，每个UCM组件必须在Git中表示为存储库。
子模块需要额外修改，如“true nature of submodules”中所述
但是他们会记录一个特定的SHA1，当你拉动每个“APP”时，这就是你想要的
gitslave允许您将Tools与“Appx”更紧密地联系起来，但我认为这不符合您的情况。
请注意，使用子模块将：
Tools'设为'APPx'