从 ClearCase 迁移到 Git

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

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

正如您所看到的，稳定主干仅包含已合格的版本。我在 Git 中复制此工作流程时遇到问题，因为版本 B、C 和 D 也被推入 QA 主干，随后推入稳定主干。在我看来，这违背了仅包含稳定版本的“干净”主干的目的。

现在，Git 和 ClearCase 之间存在明显的根本差异，我确信这解释了为什么我在使用以前的概念来指定工作流程时遇到困难。

几天来我一直在尝试了解这些新的 SCM 工具（我也研究过 Mercurial），并且确实可以使用一些关于如何继续的指示。我们正在 Mac 和 Windows PC 上进行开发，与命令行相比，绝大多数团队更喜欢 GUI 工具。

谢谢！ :-)

首先你可以阅读这篇文章ClearCase 和 Git 的比较

正如中所解释的子模块和分支之间的中间地带？，当来自 ClearCase 时可能会欺骗您的一个概念是组合（配置继承）的概念：请参阅灵活分支与静态分支（GIT 与 Clearcase/Accurev）.

ClearCase 按文件工作（或按活动工作，每个活动都是一组文件）。
Git 按 Blob 增量工作（每个 Blob 代表一个content：如果两个文件内容相同，则只会存储一个“blob”）

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

• 提交重新排序（rebase --interactive，这是“git”方式，在 Mercurial 中不推荐）
• and/or 出版物（这是一个正交维数分支，特定于 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

• 重新排序+发布 (push):

您还可以通过自己的 git 存储库来表示每个代码升级。
一旦提交按正确顺序排列，您就可以将相关分支推送到 QA 存储库或稳定存储库。

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

• Mercurial 不鼓励，同时被技术上可行
• 当开发人员拉取其他人已重新基址（重新排序）的分支时出现问题：请参阅从上游 REBASE 中恢复的部分git rebase手册页。

也可以看看：

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