从ClearCase转移到Git [英] Moving from ClearCase to Git
问题描述
我来自ClearCase背景，我们（简单地说）的工作流程由三个步骤组成，其中最左侧的干线不稳定，中间的干线是质量保证，最右侧的是稳定的。即
A A A
| | |
B C |
| / | |
C | E
| | /
D E
| /
E
正如您所看到的，稳定的中继线仅包含合格的版本。我在Git中复制这个工作流时遇到了问题，因为版本B，C和D也被推入QA中继线，并随后被推入稳定的中继线。在我眼中，这打破了只包含稳定版本的干净主干的目的。
现在Git和ClearCase之间有明显的根本区别，我确信解释了为什么我我很难用我以前的概念来指定工作流程。
我一直在试图绕过这些新的SCM工具（我也看过Mercurial ）好几天了，真的可以使用一些关于如何着手的指示。我们正在开发Mac和Windows电脑，与命令行相比，绝大多数团队更喜欢GUI工具。
谢谢！ ： - ）
作为基础的clearcase-concepts-every-developer-should-know / 645771＃645771在子模块和分支之间的中间地带？中解释，当来自ClearCase时可能会欺骗你的一个概念是组合（配置继承）的概念：参见灵活与静态分支（GIT vs Clearcase / Accurev）。
$ b ClearCase按文件（或活动）通过活动，每个活动都是一组文件）。
Git按blob delta（每个blob表示一个内容）工作blob delta：如果两个文件具有相同的连续只有一个blob将被存储）
这意味着您通过分支/流和活动（如果您使用的是UCM）在ClearCase中执行的操作，将更有可能通过以下方式实现：
重新排序+正交维度到分支，特定于DVCS的版本控制/ 2563917＃2563917合并（仅针对尚未发布的提交，即未推送）：
您将重新排序适用于您的代码的修改增量，以便仅合并您想要的内容。
trunk =>主干'QA => QA'stable
A B'
| |
B D'
| |
C A'---- A'C''
| | | |
D C'C'A'' - A''（ - ：合并到分支）
| | | | |
EEEEE
- 重新排序+出版物（推）：
您也可以通过自己的git仓库来代表每个代码升级。
一旦这些提交按照正确的顺序进行，您就可以将相关分支机构推送到QA回购或稳定回购。
重新排序（历史重写）是：
git rebase
另请参阅：
>
I'm coming from a ClearCase background where we (simply speaking) had a workflow made up of three steps where the leftmost trunk was unstable, middle trunk is Quality Assurance and the rightmost was stable. i.e.)
A A A
| | |
B C |
| /| |
C | E
| | /
D E
| /
E
As you can see the stable trunk contains only the versions that have been qualified. I'm having problems replicating this workflow in Git as versions B, C and D are also pushed into the QA trunk and subsequently the stable trunk. In my eyes this defeats the purpose of a "clean" trunk containing only stable versions.
Now there's obviously fundamental differences between Git and ClearCase which I'm sure explains why I'm having trouble using my previous conceptions to specify a workflow.
I've been trying to wrap my head around these new SCM tools (I've looked at Mercurial too) for a couple of days now and could really use some pointers on how to proceed. We're developing on Mac and Windows PCs and the vast majority of the teams prefer GUI tools compared to command line.
Thanks! :-)
First you can read this comparison between ClearCase and Git
As explained in Middle-ground between submodules and branches?, the one concept which is likely to trick you when coming from ClearCase is the notion of composition (configuration inheritance): see Flexible vs static branching (GIT vs Clearcase/Accurev).
ClearCase works file by file (or activity by activity, each activity being a group of files).
Git works blob delta by blob delta (each blob representing a content: if two files have the same content, only one "blob" will be stored)
That means what you are trying to do in ClearCase through branch/streams and activities (if you are using UCM), will more likely be achieved through:
- commit reordering (rebase --interactive, which is the "git" way, and not recommended in mercurial)
- and/or publication (which is an orthogonal dimension to branching, specific to DVCS)
reordering + merge (only for commits not yet "published", ie not pushed):
You are reordering the modifications deltas applied to your code, in order to merge only what you want.
trunk => trunk' QA => QA' stable
A B'
| |
B D'
| |
C A'----A' C''
| | | |
D C' C' A''-- A'' (--: merge to branch)
| | | | |
E E E E E
- reordering + publication (push):
You can also represent each code promotion by a git repo of its own.
Once the commits are in the proper order, you push the relevant branches to a QA repo, or a stable repo.
The reordering (history rewriting) is:
- not encouraged in Mercurial, while being technically possible
- problematic when a developer pull a branch someone else has rebased (reordered): see the RECOVERING FROM UPSTREAM REBASE section of the
git rebaseman page.
See also:
这篇关于从ClearCase转移到Git的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
