如何将git桥接到ClearCase？
我最近使用了git svn ，非常喜欢它。 现在我正在另外一个客户开始一个新的项目。 在那个地方，SCM的select是ClearCase。 我还没有find一个相当于ClearCase的git svn 。 有没有人曾试图在本地使用git作为ClearCase的前端，使用一些技巧，configuration或脚本以及任何成功的措施？ 如果可以，请解释使用的方法？
这里有一个避免劫持的方法，我们的团队在一年多的时间里成功地使用了这个方法，直到我们退休了Subversion的ClearCase（根据公司政策，虽然这是我们团队的后退步骤 – 我们基本上只是把ClearCase当作一个笨蛋文件系统，并在git中本质上工作，但现在我们正在使用git-svn桥，而不是原生git。）
我们使用了两个目录，一个用于ClearCase快照和master git repo，我们在整个团队之间共享，从未编辑过文件，另一个用于我们的“工作”目录。
ClearCase快照视图中的准备工作是：
％git init ％git add ** / *。cxx ** / *。h ** / Makefile（依此类推） ％git commit -m“initial”
然后克隆你的工作目录：
％mkdir〜/ work ％git clone / path / to / repo
在分支上的工作目录中工作：
％git checkout -bfunction ％...编辑/编译... ％git add -u ％git提交
确保ClearCase快照是最新的（它始终是我们的，因为我们在团队之间共享它，我们都使用git）。
然后通过重新绑定将分支合并到主分支，以避免自动合并提交：
％git checkout master ％git拉 ％git结帐function ％git rebase master ％git checkout master ％git合并function ％git分支-dfunction ％git diff --name-status origin / master
根据git diff --name-status的输出，通过检出/ mkelem / rmname任何已更改/新/已删除的文件来准备ClearCase视图。 我们用手卷脚本来做到这一点。 不要忘记检查任何已添加/删除文件的目录：
然后把git的东西放回去，用ClearCase检查：
％git推送 ％cd / path / to / repo ％git reset --hard ％cleartool ci`cleartool lsco -r -short -me`
它看起来像很多命令，但这包括设置，并且您的每日工作stream程不使用许多命令。 您可以在推回到ClearCase的步骤中简单地构build一个脚本，并随着每个人都习惯于基本的工作stream程，逐渐发现/向您的团队展示所有酷炫的Git东西。
这个系统的真正之处在于，在所有人都能胜任git之后， 你可以轻易地将ClearCase和所有相关的猴子工作和收费。 也许给该公司的ClearCase家伙一个非常需要的假期，并节省一些再培训。 （不幸的是，在我的公司，git的东西都是skunkworks，我们已经转移到了Subversion–从ClearCase转发，但是从git转向！）
我强烈build议您使用ClearCase全局本地的pristine脚本，本地运行在ClearCase快照视图中，并确保它与git同步。 我们将其设置为每天运行两次的cron作业，并且在我们将要推回到git时手动运行它。 不幸的是，博客文章的链接不再有效。 但是脚本在Github上仍然可用。
虽然它可能不是没有几个疣（你已经被警告），我觉得我应该提到我已经写了一个桥梁。
http://github.com/charleso/git-cc
两个系统之间的桥接并不容易，我希望我的解决scheme是git-svn的一半。 一个很大的限制是你真的只能镜像一个单一的stream; git-cc无法克隆所有的Clearcase分支（就像那样好）。 但是，鉴于大多数替代脚本围绕着一个Clearcase视图解决，您不会变得更糟（IMO）。
就我个人而言，我发现历史相当重要，其他解决scheme所缺乏的是它们将历史导入Git。 能够对文件执行git-blame并查看其真实作者是非常有用的。
如果没有其他的git-cc可以处理上面的Matt解决scheme中提到的“git log –name-status”步骤。
我当然好奇听到VonC和Matt（以及其他人）对此的看法，因为我同意任何与Clearcase的桥梁都充满了困难，并且可能比它的价值更麻烦。
我通常遵循的一个过程是：
- 在ClearCase
view/vobs/myComponent快照cd - git init。
这使我可以将ClearCase组件视为Git仓库。
然后，我可以在该回购中执行所有需要的分支和“私人”提交，使得文件可以按需要写入（可能在快照视图中）。
一旦我有一个稳定的最终提交，我更新我的快照视图，列出所有“劫持”的文件：我签出他们，并签入他们回到ClearCase。
考虑到Git限制 ，每个ClearCase（UCM）组件的回购是适合Git回购的大小。
另请参见每个开发人员应该知道的基本清晰概念是什么？ 用来比较ClearCase和Git。
这个想法依然是：
- 没有git-cc
- 无需导入ClearCase的所有历史logging（与SVN版本不同，它没有存储库基线的概念）
- 在ClearCase视图中为中间提交创build一个Git仓库
- 通过签入所有修改的文件，在ClearCase视图中镜像最终的Git提交。
