git - 使用ClearCase和Git走向理想的工作流程

Question

介绍
这不仅仅是一个事实，使用clearcase（而不是ucm）作为由很少人维护的大型项目的主scm是一个相当不高效的解决方案。当它成为企业标准时，我们就要坚持下去，我们需要找到一个有效的解决办法。
clearcase通常的工作流由一个master分支、一个develop分支和几个新的特性分支组成。

        o--------o (feature)
       /          \
  ----o--o---o-----o----o (develop)
 /        \         \
*----------o---------o (main)

例子
实际上，我所说的特性也可以是一个简单的重构，比如在项目内部进行大规模的重命名。在这个例子中，由于clearcase是以文件为中心的，我们总是需要一个临时分支（在非ucm cc中没有原子签入）。创建一个新的分支是痛苦的，拥有正确的配置规范是一项艰难的任务。从这里，我看到两种解决方案：
与公司合作，开始大规模地检查所有文件。因为scm环境与clearcase服务器不在同一个站点上，所以一切都变慢了。我计算每个文件2个，1k个文件8分钟。在第一次喝咖啡休息之后，我们完成工作，并签入所有文件（又浪费了8分钟）。一些测试，一个新的大规模签出，一个错误修复，一个大规模签入，合并到develop分支，最后我们删除feature分支，这不再有用。
在这个解决方案中，一切都很慢，大量咖啡因被消耗，工作流程效率很低。我认为这不是一个好的解决办法。
因为我们希望跟踪更改，并且不想浪费时间签入/签出项目的所有文件，所以我们从快照视图初始化git存储库。实际上，git存储库可以位于clearcase之外的任何地方。这些更改是在git的帮助下在本地进行的，一旦所有的事情都完成了，这个项目就会用clearfsimport在clearcase上推后。之后，我们仍然需要合并feature分支。这是在CC中完成的。然后可以删除特征分支。
这个解决方案需要很多操作。此外，如果我们拼错了目标视图，或者忘记删除所有临时文件，clearfsimport可能非常危险。最后但并非最不重要的是，最后的合并必须在cc上完成。
快照视图
在我的示例中，我没有提到快照视图，因为它们与git不兼容。根据时间戳识别的被劫持的文件。如果我手动修改一个文件并恢复其原始修改日期，clearcase将不会看到任何更改。这可能是非常危险的，因为下面的例子证明了这一点。
如果你不相信我，你可以试试这个：

stat -c 'touch --no-create -d "%y" "%n"' foo > restore_timestamp
echo "ClearCase will not see this" >> foo
source restore_timestamp
rm restore_timestamp

有了这个机制，任何git存储库都不能驻留在clearcase快照视图中。
分离的git存储库
我怀疑我们能否找到临时创建分支所需的任何解决方法。合并必须在clearcase上完成，尽管git保留了所有东西。
我试着广泛地使用复制/粘贴来将完全分离的git存储库与clearcase同步。在最后合并之前，我将develop分支的当前状态复制/粘贴到一个新的git分支中，并尽快进行合并。最后，我使用clearfsimport将修改推回到develop分支。
如果有人想在合并过程中访问项目，则此操作可能非常危险。因此，在操作期间必须锁定或保留开发分支。不幸的是，这个额外的操作在clearcase上非常耗时。
clearcase的“git checkout-b特性”等价物
在git中，当我想创建一个新的分支时，我只需键入：

 git checkout -b feature

仅此而已，我可以马上开发我的新功能。在ClearCase上，情况有点不同。
首先，我需要在我想创建分支的地方放置一个标签。从Windows和Cygwin，我可以做到：

LABEL=my_temporary_label
VOB=vob_name
cleartool mklbtype -global -nc lbtype:${LABEL}@\\${VOB}
cleartool mklabel -replace ${LABEL} `cleartool find . -cview -print -nxn | awk '{printf "%s ", $0}'`
cleartool find . -cview -type l -exec 'cleartool ls %CLEARCASE_XPN%' | \
   perl -p -e 's/\\/\//g' | \
   perl -p -e 's/\r//g' | \
   perl -e 'while(<>) {s@([.]/)(.*/)(.*-->\s*)@$2@;print;}' | \
   xargs -n1 cleartool mklabel ${LABEL}

但是，我们需要小心，因为符号链接没有扩展。
然后，必须创建一个分支：

mkbrtype –c "Temporary Branch" my_temporary_branch 

要处理此分支，需要创建一个视图：

cleartool mkview -tag my_temporary_view \\shared\path\to\viewStorage\my_temporary_view.vws

必须编辑配置规范：

element * CHECKEDOUT
element  .../lost+found -none

element * .../develop_branch/LATEST

mkbranch develop_branch
   element * /main/A_LABEL_WHERE_THE_BRANCH_IS_BRANCHED_ON
   element * /main/LATEST

end mkbranch develop_branch

现在，分支被创建。我们可以做我们的特写。放松点，嗯？
在git中，我通常每天创建3-5个分支。我想我不能用ClearCase做同样的事。我错了吗？
讨论
这两个建议的解决方案远远不够好，因为它们都需要在clearcase上进行大量耗时的操作（创建分支、设置视图、签入、签出、执行合并、删除分支）。
我正在寻找一个不涉及复杂操作的解决方案。我仍然相信git可以是一个很好的盟友，但是clearcase和git怎么能一起工作呢？
我想我们可以用一些脚本。我最近发现git-cc可能是个好的开始。不幸的是，这个项目还不成熟。
我还没有研究过这种方法，但我认为有一种解决方案可以在git中使用clearcase快照视图。在进行任何更改之前，必须保存每个文件的时间戳：

 find . -type f -exec stat -c 'touch--no-create -d "%y" "%n"' {} \; > restore

从那里，我们可以在git上工作，一旦到了在clearcase上推送更改或从开发分支中拉取更改的时候，就可以在所有文件上恢复原始时间戳，但是修改后的文件可以在上次同步之后恢复：

 source ./restore
 git diff --name-only SHA1 SHA2 | xargs touch

问题
在stackoverflow上，人们喜欢精确的问题，而不是基于基本观点的问题。因此，经过长时间的介绍，我终于可以问自己一个问题：
我尝试了许多不同的方法来改进我的clearcase工作流程，但是使用以文件为中心的scm来处理大型项目并不简单。我相信git可以帮上大忙，但我需要找到一个允许本地存储库与clearcase同步的工作流，如果可能的话，不需要临时分支。
能做到吗？

Answer 1

VonC可能的解决方案
在VonC的answer中，他建议不要使用中间分支，使用git管理所有内容。
我想通过一个例子来说明他的方法。我们从clearcase上的这个配置开始：

  o------o----o (develop)
 /        \ 
*----------o (main)

其思想是使用git来促进一个新特性的开发，该特性最终将合并到develop分支。
我们首先将CurraseWork项目复制到本地文件夹中，并输入Git存储库（在GIT存储库不存在的情况下）。

WORKSPACE=~/foo
cp `cleartool ls -r | grep '@@' | sed 's/@@.*$//'` $WORKSPACE
cd $WORKSPACE
git init
git add .
git commit -m "Initial commit"
git checkout -b feature

我们花了一些时间在它自己的本地git分支上开发这个特性：

                  x----x--x---x----x (feature on Git)
                 /
                x---------- (master on Git)
               /
  o------o----o------o----o (develop)
 /        \ 
*----------o (main)

在一天结束时，是时候从clearcase中同步可能的更改了：

git checkout master
git --ls-files | xargs rm
cd $CCVIEW
cleartool ls -r | grep '@@' | sed 's/@@.*$//' > $WORKSPACE/ccview
cd $WORKSPACE
cat ccview | xargs -n1 cp {} $WORKSPACE    
cat ccview | xargs git add 
git commit -m "Imported from CC"

所以现在我们已经对feature分支进行了多次提交，mastergit分支与clearcase同步。

                  x----x--x---x----x (feature on Git)
                 /
                x-----------o (master on Git)
               /           /
  o------o----o------o----o (develop)
 /        \ 
*----------o (main)

在整个合并过程中，我们不能忘记锁定clearcase视图。这样做是为了防止其他开发人员看到自己的更改被clearfsimport删除。要锁定ClearCase分支很容易：

cleartool lock brtype:$BR_NAME 

然后可以在git上进行合并：

git checkout master
git merge feature

git分支与feature合并。

                  x----x--x---x----x (feature on Git)
                 /                  \
                x-----------o--------o (master on Git)
               /           /
  o------o----o------o----o (develop)
 /        \ 
*----------o (main)

修改可以推回到clearcase

OUT="$(mktemp -d)"
cp -v --parents `git ls-files | sed 's/[^ ]*\.gitignore//g'` $OUT
clearfsimport -comment 'clearfsimport' -rec -unco -nset $OUT $CVIEW    
rm -rf $OUT

并且可以移除锁以重新授权分支上的更改

cleartool unlock brtype:$BR_NAME

是的。

                  x----x--x---x----x (feature on Git)
                 /                  \
                x-----------o--------o (master on Git)
               /           /          \
  o------o----o------o----o------------o (develop)
 /        \ 
*----------o (main)

Git存储库和本地工作区可能会被删除，除非我们需要继续。

  o------o----o------o----o------------o (develop)
 /        \ 
*----------o (main)

在这个解决方案中，我们没有在clearcase上使用中间分支，所有的合并过程都发生在git上。ClearCase历史被保留下来。唯一不好的地方是需要为最终合并锁定开发分支。
@VonC，如果我错了，请随意修改我的答案。