Question

我来自ClearCase背景，我们（简单来说）的工作流程由三个步骤组成，其中最左边的行李箱不稳定，中间行李箱是质量保证，最右边是稳定的。即。）

A  A  A
|  |  |
B  C  |
| /|  |
C  |  E
|  | /  
D  E
| /
E

正如您所看到的，stable trunk仅包含已经过限定的版本。我在Git中复制这个工作流程时遇到了问题，因为版本B，C和D也被推入QA主干和随后的稳定主干。在我看来，这打破了仅包含稳定版本的“干净”行李箱的目的。

现在Git和ClearCase之间存在明显的根本区别，我肯定会解释为什么我在使用以前的概念来指定工作流时遇到了麻烦。

我一直试图围绕这些新的SCM工具（我已经看过Mercurial）了解了几天，真的可以使用一些关于如何继续的指示。我们正在开发Mac和Windows PC，与命令行相比，绝大多数团队更喜欢GUI工具。

谢谢！： - ）

Answer 1

首先，您可以阅读此comparison between ClearCase and Git

正如Middle-ground between submodules and branches?中所解释的那样，来自ClearCase时可能会欺骗你的一个概念是组合概念（配置继承）：见Flexible vs static branching (GIT vs Clearcase/Accurev)。

ClearCase逐个文件工作（或活动活动，每个活动都是一组文件） Git通过blob delta工作blob delta（每个blob代表内容：如果两个文件具有相同的内容，则只存储一个“blob”）

这意味着您通过分支/流和活动（如果您使用的是UCM）在ClearCase中尝试做的事情，更有可能通过以下方式实现：

提交重新排序（rebase --interactive，这是“git”方式，不建议使用mercurial）
和/或发布（这是orthogonal dimension分支，特定于DVCS）

重新排序+合并（仅适用于尚未“已发布”的提交，即未推送）：
您正在重新排序应用于代码的修改增量，以便仅合并您想要的内容。

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

重新排序+发布（推送）：

您还可以通过自己的git repo代表每个代码促销一旦提交的顺序正确，您就可以将相关分支机构推送到QA仓库或稳定仓库。

重新排序（历史重写）是：

not encouraged in Mercurial，同时为technically possible
当开发人员拉出其他人已重新定位的分支（重新排序）时会出现问题：请参阅RECOVERING FROM UPSTREAM REBASE手册页的git rebase部分。

另见：

从ClearCase迁移到Git

1 个答案: