Clearcase vs Git版本控制 [英] Clearcase Vs Git version control
问题描述
我们正在使用多站点 clearcase 存储库，并且通常我们需要合并和构建我们的系统，此合并和复制需要近3天才能在各个站点上提供。因此，为了提高效率，我们计划转移到 Git 版本控制。如果我们从Clearcase迁移到Git，您能否告知我们可能遇到的潜在缺陷？
在这样一个以ClearCase为中心的视图中问了一个问题，以前从未使用过ClearCase的人不能理解这个问题。事实上，Git是ClearCase的光明前景，它是商业SCM需要赶上OSS系统。
我对ClearCase和git都有经验，我可以告诉你，ClearCase的查找合并（错误）功能是基于版本控制文件的（基本上是破坏的）设计的结果，但是在git中，你不需要这样一个原始工具来合并你的私有分支共享分支。 ClearCase是面向文件的，checkin-s是基于文件的，这就是为什么你需要Find（文件）来合并实用程序，但git是基于提交的，这是正确的模式，因为当你解决问题或实现功能，整个变更集或它们都不是唯一有意义的选项。
Git具有非常强大的合并功能，它做对了，有两种方法做你在问什么（更新你的私人分支是共享分支+你的改变）。
最明显的是做一个合并，所以在你的私人你可以这样做：
git merge sharedbranch
那么，如果存在冲突（真的比ClearCase更稀有），那么解决它们并且
git commit
就是这样。作为奖励，因为git在本地拥有所有历史记录，所以如果您拥有大量文件（如您在ClearCase中执行的操作），那么您不必浪费无数个小时，合并速度非常快，直到ClearCase在动态视图中执行合并10个文件，git可能会很容易地合并100个。
使用 git merge 意味着您保存历史记录，并且如果您的历史记录看起来像合并前：
$ p $ o --- 1 --- 2 --- 3（共享分支）
\\ \\ b $ b a --- b --- c（privatebranch）
合并后看起来像这样：
pre $ o --- 1 --- 2 --- 3（共享分支）
\\ \\\
a --- b --- c --- m（privatebranch）
这保留了您的更改历史记录，并且可以允许其他人审阅您的工作。
然后记住，这些不是文件修订历史记录，如果历史树历史记录是唯一有意义存储的历史，即使是分支只有1或2个文件不同，你想保存的状态是树，而不是一个文件。第二个选择是使用rebase，这意味着你使它看起来像你的更改已从共享分支上的最新代码开始。
您使用的命令（同时在私有分支上）：
git rebase sharedbranch
历史树将从以下变更：
o --- 1 --- 2 --- 3 （sharedbranch）
\
a --- b --- c（privatebranch）
到
o --- 1 --- 2 --- 3（共享分支）
\\ \\
a' - b' - c'（privatebranch）
给git一些时间来理解它，并且使用它，你会发现git模型有多好，以及ClearCase模型的破坏程度如何。
BTW， ClearCase中的孪生兄弟问题根本就没有因为git没有跟踪目录（相信我，你不需要这样做）。
另外，如果你的配置规范有点复杂有几个分支，并且你将文件从一个分支迁移到另一个分支，你可能知道规则在配置规范中的顺序是多么重要，并且由于配置规范是错误的而看到旧版本的文件是多么令人沮丧。在ClearCase中发生这种情况的原因在于它的基础设计，不用说，这种垃圾不会在git中发生。
因此，总而言之，git不会有一个原始的工具，如查找合并，因为它不需要它。它有一个卓越的模型和卓越的合并模型，实际工作。与ClearCase（CCRC静态视图或动态视图，您将其命名）相比，它闪电般快速。ClearCase可以有一个边缘的唯一地方是动态的即时更新视图，但这也可以通过您可以输入更快的 git checkout分支来缓解，因为您可以更新配置规范。
We are using multisite clearcase repository, and often we require to merge and build our system, this merge and replication takes almost 3 days to be available across sites. Hence to be more efficient we are planning to move to Git version control. Could you pls advise of the potential drawback that we can encounter if we move to the Git from Clearcase?
@zzz777: Your question was asked in such a ClearCase centric view that it failed to be comprehensible to people who never used ClearCase before. In fact, Git is light years AHEAD of ClearCase, it is commercial SCMs that need to catch up with OSS systems.
I have experience with both ClearCase and git and I can tell you that the Find merges (mis)feature of ClearCase is a result of its (fundamentally broken) design based on versioning files, but in git you don't need such a primitive tool to merge to your private branch the shared branch. ClearCase is file-oriented, and checkin-s are file based, that's why you need the Find (files) to merge utility, but git is commit based, and that is the right model, since when you fix an issue or implement a feature, the entire changeset or none of it are the only options that make sense.
Git has a very powerful merge feature and it does the right thing, and there are two ways to do what you are asking (updating your private branch to be the shared branch + your changes).
The most obvious is to do a merge, so while on your private branch you just do:
git merge sharedbranch
then, if there are conflicts (really a lot more rare than in ClearCase), ou resolve them and
git commit
And that's it. As a bonus, because git has all history locally, you don't have to waste countless hours, if you have lots of files, like you do in ClearCase, the merge is blazingly fast, by the time ClearCase in a dynamic view does a merge of 10 files, git will probably finish merging 100, easily.
Using git merge means that you preserve history and if your history looked like this before the merge:
o---1---2---3 (sharedbranch)
\
a---b---c (privatebranch)
after the merge it will look like this:
o---1---2---3 (sharedbranch)
\ \
a---b---c---m (privatebranch)
This preserves the history of your changes and can allow others to review your work.
And remember, these are NOT file revision histories, these if the tree history, which is the only history that makes sense to store, even if branches differ only by 1 or 2 files, the state you want to preserve is the tree, not one file.
The second option is to use rebase, which means that you make it like it seems al your changes have been made starting from the latest code on the shared branch.
The command you use (again, while on the private branch):
git rebase sharedbranch
The history tree will change from:
o---1---2---3 (sharedbranch)
\
a---b---c (privatebranch)
to
o---1---2---3 (sharedbranch)
\
a'--b'--c' (privatebranch)
So if you give git some time to understand it, and use it a little, you'll see how much better is the git model and how broken the ClearCase model is.
BTW, the evil twin problem in ClearCase simply does not exist in git because git does not track directories (trust me, you do NOT need that).
Also, if you ever had a config spec which is a little more complicated with several branches and you migrated files from one branch to the other, you probably know how important the order of the rules in the config spec is, and how frustrating is to see old versions of files because the config spec is "wrong". That happens in ClearCase due to its base design, and, needless to say, that kind of crap can't happen in git.
So, to conclude, git does not have a primitive tool such as "find merge" because it does not need it. It has a superior model and superior merge model which actually works. It is lightning fast compared to ClearCase (CCRC static view or dynamic view, you name it).
The only place ClearCase could have an edge is the instantaneous update of the dynamic view, but that is also mitigated by the fact that you can type faster git checkout branch than you can update the config spec.
这篇关于Clearcase vs Git版本控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
