如何将 git 桥接到 ClearCase？

How to bridge git to ClearCase?

提问by Bas Bossink

I've recently used git svnand enjoyed it very much. Now I'm starting a new project at a different customer. At that site the SCM of choice is ClearCase. I haven't found a baked equivalent of git svnfor ClearCase. Is there anybody who has tried to use git locally as a front-end to ClearCase using some tricks, configuration or scripting with any measure of success? If so can you please explain the method used?

我最近使用git svn并非常喜欢它。现在我正在为不同的客户开始一个新项目。在该站点上，选择的 SCM 是 ClearCase。我还没有找到git svnClearCase的烘焙等价物。是否有人尝试使用一些技巧、配置或脚本在本地使用 git 作为 ClearCase 的前端并取得任何成功？如果可以，请解释一下使用的方法吗？

采纳答案by Matt Curtis

Here's a method that avoids hiHymans, which our team used this method quite successfully for over a year, until we retired ClearCase for Subversion (per company policy, although it is a backwards step for our team - we were basically just using ClearCase as a dumb file system, and virtually working natively in git, but now we're using the git-svn bridge which isn't as nice as native git.)

这是一种避免劫持的方法，我们的团队在一年多的时间里成功地使用了这种方法，直到我们为 Subversion 停用了 ClearCase（根据公司政策，尽管这对我们的团队来说是一个倒退 - 我们基本上只是使用 ClearCase 作为一个愚蠢的文件系统，并且实际上在 git 中本地工作，但现在我们使用 git-svn 桥，它不如本地 git 好。）

We used two directories, one for the ClearCase snapshot and master git repo, which we shared among the whole team and never edited files in, and one for our "working" directory.

我们使用了两个目录，一个用于 ClearCase 快照和主 git 存储库，我们在整个团队之间共享并且从未编辑过其中的文件，另一个用于我们的“工作”目录。

The preparation in the ClearCase snapshot view is:

ClearCase 快照视图中的准备工作是：

% git init
% git add **/*.cxx **/*.h **/Makefile (and so on)
% git commit -m "initial"

Then clone in your working directory:

然后克隆到您的工作目录中：

% mkdir ~/work
% git clone /path/to/repo

Work in the working directory, on a branch:

在工作目录中工作，在一个分支上：

% git checkout -b feature
% ...edit/compile...
% git add -u
% git commit

Make sure the ClearCase snapshot is up-to-date with pristine(which it always was for us, because we shared it among the team, and we all used git).

确保ClearCase的快照上最新与原始的（它始终是我们的，因为我们的团队之间共享它，大家都习惯GIT）。

Then merge the branch onto the master by rebasing it, to avoid an automatic merge commit:

然后通过 rebase 将分支合并到 master 上，以避免自动合并提交：

% 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

Prepare the ClearCase view by checking out/mkelem/rmname any changed/new/removed files, based off the output of git diff --name-status. We used a hand-rolled script to do this. Don't forget to check out any directories that have added/removed files:

根据git diff --name-status. 我们使用手卷脚本来做到这一点。不要忘记检查已添加/删除文件的任何目录：

Then push the git stuff back, and check in with ClearCase:

然后将 git 东西推回去，并使用 ClearCase 签入：

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

It seems like a lot of commands, but this includes setup, and your daily workflow doesn't use many commands. You can trivially build a script around the push-back-to-ClearCase step, and discover/show your team all the cool extra git stuff gradually as everyone gets used to the basic workflow.

看起来命令很多，但这包括设置，您的日常工作流程不会使用很多命令。您可以围绕 push-back-to-ClearCase 步骤轻松构建脚本，并随着每个人都习惯了基本工作流程，逐渐发现/向您的团队展示所有很酷的额外 git 东西。

The real beauty of this system is, after a while when everyone's competent with git, you can trivially ditch ClearCaseand all the associated individual monkey work and fees. Maybe give the company's ClearCase guy a much needed holiday and some retraining with the savings. (Sadly at my company the git stuff was all skunkworks, and we've moved to Subversion - forwards from ClearCase but backwards from git!)

这个系统的真正美妙之处在于，当每个人都能够熟练使用 git 后，您可以轻松地放弃 ClearCase和所有相关的个人猴子工作和费用。也许给公司的 ClearCase 员工一个急需的假期，并用储蓄进行一些再培训。（可悲的是，在我的公司，git 的东西都是 skunkworks，我们已经转移到 Subversion - 从 ClearCase 向前但从 git 向后！）

I stronglyrecommend you use the pristinescript from ClearCase Globally, Git Locally, which runs in the ClearCase snapshot view and ensures it and git are in sync. We set this up as a cron job that ran twice daily, and also ran it manually whenever we were about to push back to git. Unfortunately the link to the blog post is no longer valid. However the script is still available on Github.

我强烈建议您使用pristine来自ClearCase Globally、Git Locally的脚本，该脚本在 ClearCase 快照视图中运行并确保它与 git 同步。我们将其设置为每天运行两次的 cron 作业，并且在我们即将推回 git 时手动运行它。不幸的是，博客文章的链接不再有效。但是该脚本在Github上仍然可用。

回答by charleso

While it may not be without a few warts (you have been warned), I feel I should mention I have written a bridge of sorts.

虽然它可能不是没有一些问题（你已经被警告过），但我觉得我应该提到我已经写了一个桥梁。

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

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

Bridging between the two systems isn't easy, and I wish my solution was as half as good as git-svn. A big limitation is that you're really confined to mirroring a single stream; git-cc can't clone all your Clearcase branches (as nice as that would be). However, given that most of the alternative scripts resolve around a single Clearcase view you are no worse off (IMO).

两个系统之间的桥接并不容易，我希望我的解决方案是 git-svn 的一半。一个很大的限制是您实际上仅限于镜像单个流；git-cc 不能克隆你所有的 Clearcase 分支（就像那样）。但是，鉴于大多数替代脚本都围绕单个 Clearcase 视图进行解析，因此您的情况不会更糟 (IMO)。

Personally I find history quite important and what other solutions lack is their importing of history into Git. Being able to run git-blame on files and see their real authors is quite useful from time-to-time.

我个人认为历史非常重要，其他解决方案缺乏的是将历史导入 Git。能够对文件运行 git-blame 并查看其真正的作者，这非常有用。

If nothing else git-cc can handle the aforementioned 'git log --name-status' step in Matt's solution above.

如果没有别的 git-cc 可以处理上述 Matt 解决方案中提到的“git log --name-status”步骤。

I'm certainly curious to hear what VonC and Matt (and others) think of this, as I agree that any bridge to Clearcase is fraught with difficulties and may be more trouble than it's worth.

我当然很想知道 VonC 和 Matt（以及其他人）对此有何看法，因为我同意通往 Clearcase 的任何桥梁都充满困难，而且可能带来的麻烦比其价值还多。

回答by VonC

The one process I usually follow is:

我通常遵循的一个过程是：

• snapshot cd within a ClearCase view/vobs/myComponent
• git init .

• ClearCase 中的快照 cd view/vobs/myComponent
• 混帐初始化。

That allows me to consider a ClearCase component as a Git repo.
I can then do all the branching and "private" commits I want within that repo, making the file writable as I need them (possible within a snapshot view).

这让我可以将 ClearCase 组件视为 Git 存储库。
然后，我可以在该 repo 中执行我想要的所有分支和“私有”提交，使文件在我需要时可写（可能在快照视图中）。

Once I have a stable final commit, I update my snapshot view, which list all the "hiHymaned" file: I checkout them and check-in them back to ClearCase.

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

Considering the Git limits, a repo per ClearCase (UCM) component is the right size for a Git repo.
See also What are the basic clearcase concepts every developer should know?for a comparison between ClearCase and Git.

考虑到Git 限制，每个 ClearCase (UCM) 组件的存储库是 Git 存储库的合适大小。
另请参阅每个开发人员应该知道的基本 clearcase 概念是什么？比较 ClearCase 和 Git。

The idea remains:

思路依旧：

• no git-cc
• no need to import allthe history of ClearCase (which has no notion of repository baseline, unlike the SVN revisions)
• creation of a Git repo within a ClearCase view for intermediate commits
• final Git commit mirrored in the ClearCase view through a checkin of all modified files.

• 没有 git-cc
• 无需导入ClearCase 的所有历史记录（与 SVN 修订版不同，它没有存储库基线的概念）
• 在 ClearCase 视图中为中间提交创建 Git 存储库
• 通过检入所有修改过的文件，在 ClearCase 视图中镜像的最终 Git 提交。