从ClearCase迁移到Git

Question

我来自ClearCase背景，我们（简单地说）有一个由三个步骤组成的工作流程，其中左侧的主干是不稳定的，中间的主干是质量保证，右侧的主干是稳定的。 即：

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

正如您所看到的，稳定的主干只包含已经通过测试的版本。但我在Git中复制这个工作流程时遇到了问题，因为版本B、C和D也被推送到QA主干，随后被推送到稳定主干。在我看来，这违背了“干净”的主干只包含稳定版本的目的。

现在，Git和ClearCase之间显然存在根本性的差异，我相信这就是我在使用以前的概念指定工作流程时遇到困难的原因。

我已经努力理解这些新的SCM工具（我也看过Mercurial），但已经几天了，我真的需要一些关于如何继续的指导。我们正在Mac和Windows PC上开发，绝大多数团队更喜欢GUI工具而不是命令行。

谢谢！ :-)

- MdaG

Answer 1

首先，您可以阅读ClearCase和Git的比较来了解一些基本概念。

如中间地带：子模块和分支之间所述，从ClearCase过来可能会让您感到困惑的一个概念是组合（配置继承）：请参见灵活与静态的分支（GIT与Clearcase/Accurev）。

ClearCase按文件（或活动）工作。每个活动都是一组文件。 Git按照块增量工作。每个块表示内容。如果两个文件具有相同的内容，那么只会存储一个“块”。

这意味着通过ClearCase中的分支/流和活动（如果您使用UCM），您更有可能通过以下方法实现：

- 提交重新排序（交互式变基，这是“git”的方式，在mercurial中不建议使用） - 和/或发布（这是分布式版本控制系统特有的一条正交维度）

重新排序+合并（仅适用于尚未“发布”的提交，即未推送的提交）：

您正在重新排序应用于代码的修改增量，以便仅合并您想要的内容。

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仓库来表示每个代码推广。
一旦提交按正确顺序排列，您就可以将相关分支推送到QA仓库或稳定仓库。

---

重新排序(历史重写)是:

• Mercurial不鼓励这样做，尽管在技术上是可能的
• 当开发人员拉取其他人已经变基(重新排序)的分支时会出现问题: 请参见RECOVERING FROM UPSTREAM REBASE部分git rebase手册页面。

另请参阅:

• 一个成功的Git分支模型
• 在大型组织中使用Mercurial

- VonC

---

谢谢。习惯了ClearCase，这些替代工具一开始有点让人不知所措。希望它们能在适当的时间内变得轻松自如。:-) - MdaG

@MdaG：不客气；）使用集中式版本控制系统（CVCS）和分布式版本控制系统（DVCS）已经有一段时间了，我发现了解两者之间的区别非常重要。请参见https://dev59.com/OnE85IYBdhLWcg3wl0nF - VonC