我最近使用git svn并非常喜欢它。现在我正在另一个客户开始一个新项目。在该站点，选择的SCM是ClearCase。我还没有找到ClearCase的git svn烘焙等价物。有没有人尝试使用git本地作为ClearCase的前端使用一些技巧，配置或脚本以及任何成功的衡量标准？如果是这样，请解释一下使用的方法？
答案 0 :(得分：37)
这是一种避免劫持的方法，我们的团队使用这种方法已经成功使用了一年多，直到我们退出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内容，因为每个人都习惯了基本的工作流程。
这个系统真正的美妙之处在于，经过一段时间，每个人都能胜任git，你可以轻易放弃ClearCase 以及所有相关的猴子工作和费用。也许给这家公司的ClearCase家伙带来一个非常需要的假期，并通过节省来进行一些再培训。 （可悲的是，在我的公司，git的东西都是臭鼬工具，我们已经转移到Subversion - 从ClearCase转发但是从git转发！）
我强烈建议您使用ClearCase Globally, Git Locally中的pristine脚本，该脚本在ClearCase快照视图中运行并确保它和git同步。我们将其设置为每天运行两次的cron作业，并且每当我们要回到git时也手动运行它。
不幸的是，博客文章的链接不再有效。但是，该脚本仍可在Github上使用。
答案 1 :(得分：12)
虽然可能没有一些瑕疵（你已被警告过），我觉得我应该提到我已经写了一座桥梁。
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的桥梁都充满困难，可能比它的价值更麻烦。
答案 2 :(得分：5)
我通常遵循的一个过程是：
view/vobs/myComponent 这允许我将ClearCase组件视为Git仓库 然后我可以在该repo中执行我想要的所有分支和“私有”提交，使文件可写，因为我需要它们（可以在快照视图中）。
一旦我有一个稳定的最终提交，我就会更新我的快照视图，其中列出了所有“被劫持”的文件：我签出它们并将它们签入回ClearCase。
考虑到Git limits，每个ClearCase（UCM）组件的回购是适合Git回购的大小。
有关ClearCase和Git之间的比较，另请参阅What are the basic clearcase concepts every developer should know?。
这个想法仍然存在：