如何将git桥接到ClearCase？

Question

我最近git svn很习惯和喜欢它.现在我正在另一个客户开始一个新项目.在该站点,选择的SCM是ClearCase.我没有找到git svnClearCase 的烘焙等效物.是否有人尝试使用git本地作为ClearCase的前端使用一些技巧,配置或脚本以及任何成功的衡量标准？如果是这样,请解释一下使用的方法？

Answer 1

这是一种避免劫持的方法,我们的团队使用这种方法已经成功使用了一年多,直到我们退出ClearCase for Subversion(根据公司政策,尽管这是我们团队的倒退步骤 - 我们基本上只是使用ClearCase作为哑巴文件系统,并且几乎在git中本地工作,但现在我们使用的git-svn桥不如本机git那么好.)

我们使用了两个目录,一个用于ClearCase快照和一个主git repo,我们在整个团队之间共享,从未编辑过文件,还有一个用于我们的"工作"目录.

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

% git init
% git add **/*.cxx **/*.h **/Makefile (and so on)
% 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

根据输出结果,通过检出/ mkelem/rmname任何已更改/新/已删除文件来准备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时,你可以轻易地抛弃ClearCase以及所有相关的猴子工作和费用.也许给这家​​公司的ClearCase家伙带来一个非常需要的假期,并通过节省来进行一些再培训.(可悲的是在我的公司,git的东西都是臭鼬工厂,我们已经转移到Subversion - 从ClearCase转发,但是从git转发!)

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

Answer 2

虽然它可能不是没有一些瑕疵(你已经被警告过),我觉得我应该提到我已经写了一个桥梁.

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

两个系统之间的桥接并不容易,我希望我的解决方案与git-svn一样好.一个很大的限制是你真的只限于镜像一个流; git-cc无法克隆你所有的Clearcase分支(就像那样好).但是,鉴于大多数替代脚本解决了一个Clearcase视图,你不会更糟(IMO).

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

如果没有别的东西,git-cc可以在上面的Matt解决方案中处理前面提到的'git log --name-status'步骤.

我当然很想知道VonC和Matt(以及其他人)对此的看法,因为我同意任何通往Clearcase的桥梁都充满困难,可能比它的价值更麻烦.

Answer 3

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

• ClearCase中的快照cd view/vobs/myComponent
• git init.

这允许我将ClearCase组件视为Git repo.
然后,我可以在该repo中执行我想要的所有分支和"私有"提交,使文件可写,因为我需要它们(可能在快照视图中).

一旦我有一个稳定的最终提交,我就会更新我的快照视图,其中列出了所有"被劫持"的文件:我签出它们并将它们签入回ClearCase.

考虑到Git限制,每个ClearCase(UCM)组件的repo是Git repo的正确大小.
另请参阅每个开发人员应该知道的基本clearcase概念是什么？用于ClearCase和Git之间的比较.

这个想法仍然是:

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