如何将Git与ClearCase桥接？

Question

如何将Git与ClearCase桥接？

41

我最近使用了git svn并非常喜欢它。现在我要在一个不同的客户处启动一个新项目，该客户选择的SCM是ClearCase。我还没有找到与git svn相对应的ClearCase工具。是否有人尝试过使用一些技巧、配置或脚本将git作为ClearCase的本地前端，并取得了一定的成功？如果有，能否请您解释一下所使用的方法？

- Bas Bossink

在我看来，使用桥接只会让事情变得更糟。ClearCase 可以作为一个简单的文件系统，你可以在其上使用完整的本地 Git - 请参阅下面我的答案中有关我们使用的方法的详细信息。 - Matt Curtis

3个回答

13

虽然这个方法不是没有缺陷的（你已经被警告了），但我想提一下，我写了一个桥接程序。

http://github.com/charleso/git-cc

在两个系统之间进行桥接并不容易，我希望我的解决方案像git-svn一样好。一个很大的限制是你只能镜像一个流; git-cc不能克隆所有Clearcase分支（尽管这将是非常方便的）。然而，考虑到大多数替代脚本都围绕单个Clearcase视图解决，你不会更糟（在我看来）。

就个人而言，我认为历史记录非常重要，其他解决方案缺少的是将历史记录导入Git。有时候能够运行git-blame命令并查看文件的实际作者非常有用。

如果没有其他更好的方法，git-cc可以处理Matt上面解决方案中提到的'git log --name-status'步骤。

我肯定很想听听VonC和Matt（以及其他人）对此的看法，因为我同意任何与Clearcase之间的桥梁都充满了困难，可能会带来更多麻烦。

- charleso

1

我会研究一下。即使只是尝试，也要加1分;) - VonC

我赞同！+1 支持 git-cc 的开发 :) - Matt Curtis

2

我们有一个相对较新的ClearCase仓库，由于CCRC 7.1.x存在无用的漏洞，今天我放弃了并尝试了您的Python导入程序。哇。历史记录轻松导入，并且似乎能够干净地跟踪主线；而且速度非常快！谢谢！ - James Blackburn

5

我通常遵循的流程是：

在 ClearCase 的视图 /vobs/myComponent 中创建快照
初始化 Git 仓库，即运行 git init .

这样我就可以把 ClearCase 组件看做一个 Git 仓库。
然后，我可以在该仓库内进行所有分支和“私有”提交操作，并根据需要将文件设置为可写（在快照视图中可能会出现这种情况）。

一旦我有了稳定的最终提交版本，我会更新我的快照视图，其中列出了所有“劫持”的文件：我会将它们检出并重新提交到 ClearCase。

考虑到Git 的限制，每个 ClearCase（UCM）组件都是一个适合作为 Git 仓库的正确大小。
另请参阅每个开发人员都应该了解的 ClearCase 基本概念？，以比较 ClearCase 和 Git。

总体思路如下：

不使用 git-cc
无需导入 ClearCase 的全部历史记录（与 SVN 版本不同，ClearCase 没有仓库基线的概念）
在 ClearCase 视图内创建 Git 仓库以进行中间提交
将最终的 Git 提交通过所有修改过的文件的 checkin 映射到 ClearCase 视图。

- VonC

@neves：并不是直接的，你需要一个脚本来查询git仓库，询问是否有重命名的文件（Git能够检测到重命名的文件），在ClearCase中检出源目录，检出目标目录（如果与源目录不同），执行“cleartool move src/file dst/renamedFile”，然后检入src和dst目录。 - VonC

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Matt Curtis · Accepted Answer

这里有一种避免劫持的方法，我们团队使用了这种方法超过一年，并且非常成功，直到我们根据公司政策将ClearCase更换为Subversion（尽管对于我们的团队来说是一个倒退步骤——我们基本上只是将ClearCase用作一个哑文件系统，并在git中实际本地工作，但现在我们正在使用git-svn桥接，这不像本地git那么好用）。我们使用了两个目录，一个用于ClearCase快照和主git仓库，我们整个团队共享它，并从未在其中编辑文件；另一个用于我们的“工作”目录。在ClearCase快照视图中的准备工作是： git init、git add **/*.cxx **/*.h **/Makefile（等等）、git commit -m “initial”。然后在你的工作目录中进行克隆：mkdir ~/work、git clone /path/to/repo。在分支上的工作目录中进行工作：git checkout -b feature、...edit/compile...、git add -u、git commit。确保ClearCase快照与pristine保持更新（对于我们来说它总是最新的，因为我们共享它，并且我们所有人都使用git）。然后通过重新设置分支将其合并到主分支上，以避免自动合并提交。

% git checkout master
% git pull
% git checkout feature
% git rebase master
% git checkout master
% git merge feature
% git branch -d feature

% git diff --name-status origin/master

通过检出/创建元素/删除元素，准备ClearCase视图中的任何更改/新文件/已删除文件，基于git diff --name-status的输出。我们使用手动脚本来完成此操作。不要忘记检出添加/删除文件的目录：

然后将git内容推回，并使用ClearCase进行签入：

% git push
% cd /path/to/repo
% git reset --hard
% cleartool ci `cleartool lsco -r -short -me`

这似乎是很多命令，但这包括设置，您的日常工作流程并不使用很多命令。您可以轻松地围绕将内容推回ClearCase步骤构建脚本，并逐渐向团队展示所有酷炫的额外git内容，让每个人都习惯基本工作流程。

这个系统真正的美妙之处是，经过一段时间，当每个人都能够熟练掌握git时，您可以轻松地放弃ClearCase和所有相关的个人工作和费用。也许可以给公司的ClearCase专员一个非常需要的假期和一些节约成本的再培训。（不幸的是，在我的公司中，git内容都是由个人完成的，并且我们已经转向Subversion-从ClearCase向前，但从git向后！）

我强烈建议您使用全局ClearCase，本地Git的pristine脚本，它在ClearCase快照视图中运行，并确保它与git同步。我们将其设置为每天两次运行的cron作业，并在准备推回git时手动运行它。不幸的是，博客文章的链接已经失效。但是该脚本仍可在Github上找到。