<p>如果您是 Rational Team Concert 用户，那么您应该知道它是一个稳健、紧密集成的源代码管理系统。但这并不意味着它适合每个软件开发项目或团队。我们为像我们一样想要了解 Git 或将在新项目中使用 Git 的 Rational Team Concert 用户编写了本文。我们对比 Git 与 Rational Team Concert 的基本和高级特性，所以您可以看到它们有哪些共性和区别。我们还将了解如何将一些常见 Git 流转换为 Rational Team Concert 中类似的源代码管理模式。最后，我们会指出在从 Rational Team Concert 迁移到 Git 时应该避免的一些陷阱。</p>    <h2><strong>基本特性和支持</strong></h2>    <p>Rational Team Concert 和 Git 都对源代码管理提供了基本和高级支持，但每个系统在源代码控制的处理上稍有不同。例如，尽管 Git 和 Rational Team Concert 都支持 <strong>分布式开发</strong> （意味着开发人员不需要在同一地点协作），但 Rational Team Concert 用户可以连接到中央服务器来共享更改和协作，而 Git 用户主要在本地克隆版本上执行操作。</p>    <p>代码存储是另一个基本特性，支持团队协作和版本控制。在 Rational Team Concert 中，用户创建一个个人服务器端存储库工作区作为其本地沙箱的镜像，然后使用自动签入功能将代码推送到存储库工作区。无论开发人员何时在其 Eclipse IDE 中执行保存操作，都会执行签入。</p>    <p>在 Git 中，用户在其本地机器上的代码 <em>分支</em> 上存储代码和工作。当他们准备就绪时，就会将完成的代码推送到远程分支。推送到远程分支的过程比使用 Rational Team Concert 的自动签入特性更加离散。因此，Git 用户通常不会像 Rational Team Concert 用户那么频繁地推送更改。</p>    <p>组织代码也是一项基本的源代码管理功能。Rational Team Concert 使用 <em>流</em> 表示团队处理的代码。流可细分为称为 <em>组件</em> 的逻辑组，可以使用流或组件来设置访问权限。</p>    <p>Git 没有提供与 Rational Team Concert 组件完全对应的实体。实际上，Git 存储库非常小，流会利用多个存储库。通常，每个存储库专门用于某个软件组件或一组相关组件。</p>    <h3><strong>IDE 集成</strong></h3>    <p>Rational Team Concert 包含一个完全集成的 Eclipse IDE，支持源代码控制管理、工作项跟踪、项目规划和编译版运行，还支持用户管理和流程管理。作为一体化解决方案，Rational Team Concert 使自定义和所有这些组件并集成到工作流中变得很容易。它还可以分别与 Rational Requirements Composer 和 Rational Quality Manager 等工具集成，以便需求收集和测试跟踪。Rational Team Concert 的功能主要受一个富客户端驱动，具有一个受服务器安装支持的 Web 客户端。一些开发人员更喜欢使用命令行客户端来执行源代码管理，但大部分 Rational Team Concert 用户直接在 Eclipse IDE 中工作。</p>    <p>就其本身而言，Git 不包含源代码管理以外的功能。核心 Git 二进制文件很小，目的是让开发人员从命令行接口高效地管理源代码。对于更喜欢它们的开发人员，Git 具有图形扩展功能，比如 EGit 和 TortoiseGit。需要存储库前端来执行项目管理的开发人员，可以选择基于 Git 的解决方案，比如 GitHub 和 BitBucket，这些解决方案提供了用户管理和问题跟踪等功能。</p>    <h2><strong>比较源代码管理架构</strong></h2>    <p>Rational Team Concert 和 Git 之间的一个关键区别是，事实上 Git 用户在一个托管在自己机器上的代码存储库中工作。这支持 Rational Team Concert 用户所没有的离线开发场景。本节将演示和比较每个源代码管理系统的基本架构和组件。</p>    <p>图 1 给出了 Rational Team Concert 的源代码控制管理系统的架构。在此图中，可以看到本地工作站上的 Eclipse 工作区，以及远程服务器上的存储库工作区和流。</p>    <p>Rational Team Concert SCM 架构</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/35261f76b05017e2d2a6e7c17b947e6e.png"></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6f9afeefda1f779fee0e0b180c823f43.png" alt="面向 Rational Team Concert 用户的 Git 指南" width="413" height="213"></p>    <p>图 2 给出了相应的 Git 架构。在此图中，可以看到本地工作站中的一个工作树和本地分支，以及远程服务器上的远程分支。</p>    <p>Git SCM 架构</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/c7d9459c9d5db013484f3eebdd40304e.png"></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/cb4d0f61d42ed4146e3fd4fb2972b95b.png" alt="面向 Rational Team Concert 用户的 Git 指南" width="491" height="150"></p>    <p>表 1 定义和比较了两个源代码管理系统的组件。</p>    <p><strong>Rational Team Concert 和 Git 的架构组件</strong></p>    <table cellspacing="0">     <caption>     比较架构和工件    </caption>     <thead>      <tr>       <th scope="col">Rational Team Concert</th>       <th scope="col">Git</th>       <th scope="col">备注</th>      </tr>     </thead>     <tbody>      <tr>       <th scope="row">存储库</th>       <td>存储库</td>       <td>两个系统中的主代码存储被称为存储库。在 Rational Team Concert 中，服务器仅保留存储库的完整副本。在 Git 中，每个用户都创建整个存储库的一个本地克隆版本。</td>      </tr>      <tr>       <th scope="row">沙箱</th>       <td>工作树</td>       <td>开发人员签出的本地文件和尚未签入 / 提交的本地更改。</td>      </tr>      <tr>       <th scope="row">流</th>       <td>分支</td>       <td>共享的代码行在 Rational Team Concert 中称为 <em>流</em> ，在 Git 中称为 <em>分支</em> 。一个简单的工作流有且仅有一个集成流或分支。在 Git 中，此分支的默认名称为 <em>主分支</em> 。</td>      </tr>      <tr>       <th scope="row">存储库工作区</th>       <td>特性分支（远程）</td>       <td>实质上，Rational Team Concert 存储库工作区是一个存储在中央服务器上的个人分支。Git 用户对分支的使用更为广泛。例如，您可以创建一个分支来支持某项特性，然后在将该特性合并到一个集成分支中后删除该分支。Git 拥有本地和远程分支，每个本地分支都 “跟踪” 到一个远程分支。</td>      </tr>      <tr>       <th scope="row">不适用</th>       <td>特性分支（本地）</td>       <td>Git 支持的离线开发场景比 Rational Team Concert 更多。Git 用户可通过本地提交操作将更改提交到任何分支，然后在离线工作时将更改推送到其远程分支。</td>      </tr>      <tr>       <th scope="row">组件</th>       <td>不适用</td>       <td>Rational Team Concert 支持通过组件对流中的代码进行逻辑分离。Git 没有与组件对应的概念。Git 用户倾向于将其开发工作分解到多个存储库。</td>      </tr>      <tr>       <th scope="row">基准 / 快照</th>       <td>标签</td>       <td>基准、快照和标签标记一个已知的代码级别，是以后创建分支的启动点。举例而言，可以创建这些工件来标记 “release 1.0”。</td>      </tr>      <tr>       <th scope="row">更改集（活动）</th>       <td>暂存更改</td>       <td>一个包含一个或多个工件更改的可变集合。</td>      </tr>      <tr>       <th scope="row">更改集（完成）</th>       <td>提交</td>       <td>一个包含一个或多个更改的不可变集合。</td>      </tr>     </tbody>    </table>    <h2><strong>比较命令和概念</strong></h2>    <p>Rational Team Concert 和 Git 的命令集非常相似。关键区别在于，Rational Team Concert 中的源代码管理采用集中管理方法，而在 Git 中，管理工作被分散到服务器存储库和本地克隆版本中。</p>    <p>在图 3 中，Rational Team Concert 用户通过签入将代码从其 Eclipse 工作区转移到存储库工作区，然后使用交付操作将代码从存储库工作区转移到远程流。接受操作将更改同时转移到存储工作区和 Eclipse 工作区。</p>    <p>Rational Team Concert 中的命令流</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/c8b7c611b0f6e2a46841eec3eb2a1eed.png"></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/d3fdc6fd45a1b407ed8202b6bb3a6356.png" alt="面向 Rational Team Concert 用户的 Git 指南" width="350" height="197"></p>    <p>图 4 展示了将代码转移到一个共享的团队分支所需执行的多个步骤。在此场景中，开发人员将更改从其工作树添加到暂存区域，将更改提交到本地分支，将更改推送到远程分支，最后合并到团队分支。拉入操作将更改从一个分支一直转移到一个工作树。</p>    <p><strong>Git 中的一个命令流</strong></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/44a18f8435c21e1d6a963318ac49f23a.png"></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/60a896ce4b8b1c5564fd161dfe20eb95.png" alt="面向 Rational Team Concert 用户的 Git 指南" width="490" height="167"></p>    <p>表 2 定义并比较了 Rational Team Concert 和 Git 中的关键命令。</p>    <p><strong>Rational Team Concert 和 Git 中的关键命令</strong></p>    <table cellspacing="0">     <caption>     比较 Rational Team Concert 和 Git 命令    </caption>     <thead>      <tr>       <th scope="col">Rational Team Concert</th>       <th scope="col">Git</th>       <th scope="col">备注</th>      </tr>     </thead>     <tbody>      <tr>       <th scope="row">签入</th>       <td>添加</td>       <td>在本地工作副本中准备将要在上游集成的更改。在 Rational Team Concert 中，此操作将更改发送到服务器进行安全保护。在 Git 中，它将更改发送到本地暂存区域。</td>      </tr>      <tr>       <th scope="row">交付</th>       <td>推送 / 合并</td>       <td>Rational Team Concert 用户将来自其存储库工作区的代码集成到一个流中。如果需要一次合并，则会阻止交付。Git 用户通常首先通过推送操作将代码交付到远程分支（称为 <em>特性分支</em> ）。在一个不同操作中，它们将此分支合并到一个主要集成分支（也称为 <em>主分支</em> ）。如果合并将需要手动干预，Git 会阻止合并，直到用户解决任何冲突。</td>      </tr>      <tr>       <th scope="row">注释 / 显示历史</th>       <td>日志</td>       <td>两个系统都提供了所有文件或所有提交内的更改的完整可跟踪性。</td>      </tr>      <tr>       <th scope="row">加载</th>       <td>克隆</td>       <td>从主存储库将源代码下载到本地工作站。Rational Team Concert 提供了部分加载存储库的能力。</td>      </tr>      <tr>       <th scope="row">接受</th>       <td>拉入</td>       <td>从主存储库上的活动分支将更改下载到本地工作区域。Rational Team Concert 的接受操作从用户连接到的流拉入所有更改。Git 的拉入操作与接受操作直接对应，它将更改从一个分支拉到另一个分支中（例如从远程分支拉到本地分支）。</td>      </tr>      <tr>       <th scope="row">不适用</th>       <td>抓取</td>       <td>从用户跟踪的所有远程分支将更改下载到其本地存储库克隆版本。用户从该分支执行拉入操作之前，抓取 <strong>不会</strong> 将用户的任何本地分支升级到该远程分支的状态。</td>      </tr>      <tr>       <th scope="row">锁定 / 解锁</th>       <td>不适用</td>       <td>锁定会阻止其他用户修改文件。Git 没有这种机制。</td>      </tr>      <tr>       <th scope="row">放弃（活动更改集）</th>       <td>取消暂存</td>       <td>在 Rational Team Concert 中，此命令从存储库工作区和本地沙箱删除更改。在 Git 中，它仅从本地分支删除更改，保持工作树原封不动。</td>      </tr>      <tr>       <th scope="row">放弃（已完成更改集）</th>       <td>重置</td>       <td>更新本地状态，就像给定更改从未下载一样。在 Rational Team Concert 中，如果向状态中引入了空白，将阻止放弃操作。Git 为其重置操作提供了多个选项。 <em>reset—hard</em> 大体相当于 Rational Team Concert 放弃操作。</td>      </tr>      <tr>       <th scope="row">状态（未决更改）</th>       <td>状态</td>       <td>两个工具都允许您通过多种方式对本地状态与远程状态进行比较。</td>      </tr>      <tr>       <th scope="row">更改您的流目标</th>       <td>签出</td>       <td>切换到不同的开发线，例如在一个维护分支上工作而不是进行主线开发。</td>      </tr>      <tr>       <th scope="row">创建快照</th>       <td>创建标签</td>       <td>使用已知标识符标记存储库的状态（例如 “Release 1.0”）</td>      </tr>      <tr>       <th scope="row">创建存储库工作区 / 流</th>       <td>创建分支</td>       <td>创建一个新开发线 / 集成点。</td>      </tr>      <tr>       <th scope="row">暂停</th>       <td>存放</td>       <td>将存储库工作区和工作树恢复到执行暂停的更改之前的状态。在 Rational Team Concert 中，暂停的更改集存储在服务器上，可归入同一个用户拥有的一个不同的存储库工作区。在 Git 中，存放完全在本地执行。</td>      </tr>      <tr>       <th scope="row">恢复</th>       <td>Git stash apply</td>       <td><em>暂停 / 存放</em> 的相反操作；此命令将暂停或存放的更改应用于用户的工作区域。</td>      </tr>      <tr>       <th scope="row">反转</th>       <td>复原</td>       <td>创建一个与相关更改 “相反” 的更改集。有效地撤销相关更改。</td>      </tr>     </tbody>    </table>    <h2><strong>理解 Git 场景</strong></h2>    <p>Rational Team Concert 和 Git 中的使用模式代表着两种根本不同的源代码管理哲学和方法。尽管开发人员倾向于在每个开发场景中以相同方式使用 Rational Team Concert（得益于它的可预测性和均匀性），Git 用户遵循且适应各种各样的使用模式。迁移到 Git 的一个重要方面是，确定哪些模式（或 Git 用语中的 <em>流</em> ）适合您的项目需求。</p>    <p>GitHub Flow 和 Git Flow 是两种最常用的 Git 模式，所以这里将看看每种模式的特征。考虑如何实现 Rational Team Concert 中的模式才有助于您在使用 Git 时采用它们。</p>    <h3><strong>GitHub Flow</strong></h3>    <p>GitHub Flow 是一个使用相对短期分支为基础的源代码控制模式，其中每个分支表示一个特定的开发或其他某个小工作单元。当该工作单元完成且所有测试都通过时，分支所有者将该分支合并到主分支，然后删除与该工作单元关联的分支。</p>    <p>如果想要在 Rational Team Concert 中实现此模式，需要先根据集成流创建一个新 “特性” 流，然后将一个或多个存储库工作流传输到它，直到开发完成。然后可以将这些存储库工作区中的一个传输到集成流，并一次交付所有更改。（回想一下，Rational Team Concert 不允许直接的流间交付。）在 Rational Team Concert 和 Git 中，如果一次合并冲突会阻止代码集成，您会收到警告。在这种情况下，系统会提示您解决合并问题。</p>    <h3><strong>Git Flow</strong></h3>    <p>Git Flow 基于 Vincent Driessen 开发的 “ 一个成功的分支模型 ”。像 GitHub Flow 一样，它使用从一个共享开发分支分叉出来的短期特性分支。主要区别是它对发布候选版使用了不同的分支，而且不会频繁地交付到主分支。</p>    <p>要与 Git Flow 建立大体对应关系，在 Rational Team Concert 中，您可以使用 “ 如何保持在 Rational Team Concert 中顺利传输流 ” 中列出的技术。在本例中，您的团队将为每日开发设置一个要合并形成的集成流，就像在 GitHub Flow 中所做的那样。然后，您可以使用一个 “发布候选版” 构建流程将集成流升级到发布候选流。接受发布候选版后，您的团队可以设置一个类似的编译版来将发布候选流升级到主流，最好使用快照标签，比如 Release 1.0。</p>    <p>因为 Rational Team Concert 允许您从任何给定快照快速创建流，所以您可以在 Rational Team Concert 中实现此模式的轻量型版本。您只需要小心地管理 Git 通常用来创建新分支的流位置上的流快照。</p>    <h2><strong>从 Rational Team Concert 迁移到 Git</strong></h2>    <p>切换到新开发工具通常需要进行一些调整。我们发现，以下流程更改支持更顺利地从 Rational Team Concert 迁移到 Git：</p>    <ul>     <li><strong>使用短期分支</strong> 。Git 流最适合包含较小工作批次的短期特性分支。Rational Team Concert 中的流可能是长期的，开发人员通常会交付较大的批次。短期、专注的流支持通过拉入请求更轻松地审核代码，而且更容易供其他开发人员合并。保持您的 Git 分支关注点紧凑，而不是一次交付太多代码。</li>     <li><strong>经常提交</strong> 。在 Rational Team Concert 中，交付的更改被分发给每个人。开发人员倾向于更长时间保留代码，以确保它在交付之前完全就绪。Git 的理念是鼓励频繁的分支，即使是简单的特性。Git 一般提交到个人分支，所以在您与主分支合并之前，您的代码不会影响其他任何用户。通过经常提交，您会留下所完成工作的详细的可审计线索。这有助于更好地完成代码审核，因为您对已更新的内容进行了说明。团队成员也能查看所有远程分支，这使他们能够轻松查看每个团队成员的工作内容，实现更有效的全团队协同配合。</li>     <li><strong>使用多个分支</strong> 。不要害怕一次打开多个分支。在 Rational Team Concert 中，可以将一个工作区域（沙箱）关联到一个存储库工作区，而 Git 允许轻松地将沙箱关联到任意多个分支。这有助于保持您的分支小而专注。通过采用多个分支，一次处理多个代码区域。当您交付时，您的代码审核工作将通过每个特定任务的分支限制到该任务。</li>    </ul>    <h2><strong>结束语</strong></h2>    <p>本文是为那些习惯使用 Rational Team Concert 且想要进一步了解 Git 的开发人员而编写的。若想成功地将您的工作流从 Rational Team Concert 调整为 Git，需要以不同方式思考如何管理和分发代码。我们的目标是帮助您理解两个源代码控制系统之间的原理、架构和命令结构差异。</p>    <p>来自：http://www.ibm.com/developerworks/cn/devops/d-guide-git-rational-team-concert-trs/index.html?ca=drs-</p>    <p> </p>