剑客
关注科技互联网

面向 Rational Team Concert 用户的 Git 指南

如果您是 Rational Team Concert 用户,那么您应该知道它是一个稳健、紧密集成的源代码管理系统。但这并不意味着它适合每个软件开发项目或团队。我们为像我们一样想要了解 Git 或将在新项目中使用 Git 的 Rational Team Concert 用户编写了本文。我们对比 Git 与 Rational Team Concert 的基本和高级特性,所以您可以看到它们有哪些共性和区别。我们还将了解如何将一些常见 Git 流转换为 Rational Team Concert 中类似的源代码管理模式。最后,我们会指出在从 Rational Team Concert 迁移到 Git 时应该避免的一些陷阱。

基本特性和支持

Rational Team Concert 和 Git 都对源代码管理提供了基本和高级支持,但每个系统在源代码控制的处理上稍有不同。例如,尽管 Git 和 Rational Team Concert 都支持 分布式开发 (意味着开发人员不需要在同一地点协作),但 Rational Team Concert 用户可以连接到中央服务器来共享更改和协作,而 Git 用户主要在本地克隆版本上执行操作。

代码存储是另一个基本特性,支持团队协作和版本控制。在 Rational Team Concert 中,用户创建一个个人服务器端存储库工作区作为其本地沙箱的镜像,然后使用自动签入功能将代码推送到存储库工作区。无论开发人员何时在其 Eclipse IDE 中执行保存操作,都会执行签入。

在 Git 中,用户在其本地机器上的代码 分支 上存储代码和工作。当他们准备就绪时,就会将完成的代码推送到远程分支。推送到远程分支的过程比使用 Rational Team Concert 的自动签入特性更加离散。因此,Git 用户通常不会像 Rational Team Concert 用户那么频繁地推送更改。

组织代码也是一项基本的源代码管理功能。Rational Team Concert 使用 表示团队处理的代码。流可细分为称为 组件 的逻辑组,可以使用流或组件来设置访问权限。

Git 没有提供与 Rational Team Concert 组件完全对应的实体。实际上,Git 存储库非常小,流会利用多个存储库。通常,每个存储库专门用于某个软件组件或一组相关组件。

IDE 集成

Rational Team Concert 包含一个完全集成的 Eclipse IDE,支持源代码控制管理、工作项跟踪、项目规划和编译版运行,还支持用户管理和流程管理。作为一体化解决方案,Rational Team Concert 使自定义和所有这些组件并集成到工作流中变得很容易。它还可以分别与 Rational Requirements Composer 和 Rational Quality Manager 等工具集成,以便需求收集和测试跟踪。Rational Team Concert 的功能主要受一个富客户端驱动,具有一个受服务器安装支持的 Web 客户端。一些开发人员更喜欢使用命令行客户端来执行源代码管理,但大部分 Rational Team Concert 用户直接在 Eclipse IDE 中工作。

就其本身而言,Git 不包含源代码管理以外的功能。核心 Git 二进制文件很小,目的是让开发人员从命令行接口高效地管理源代码。对于更喜欢它们的开发人员,Git 具有图形扩展功能,比如 EGit 和 TortoiseGit。需要存储库前端来执行项目管理的开发人员,可以选择基于 Git 的解决方案,比如 GitHub 和 BitBucket,这些解决方案提供了用户管理和问题跟踪等功能。

比较源代码管理架构

Rational Team Concert 和 Git 之间的一个关键区别是,事实上 Git 用户在一个托管在自己机器上的代码存储库中工作。这支持 Rational Team Concert 用户所没有的离线开发场景。本节将演示和比较每个源代码管理系统的基本架构和组件。

图 1 给出了 Rational Team Concert 的源代码控制管理系统的架构。在此图中,可以看到本地工作站上的 Eclipse 工作区,以及远程服务器上的存储库工作区和流。

Rational Team Concert SCM 架构

面向 Rational Team Concert 用户的 Git 指南

面向 Rational Team Concert 用户的 Git 指南

图 2 给出了相应的 Git 架构。在此图中,可以看到本地工作站中的一个工作树和本地分支,以及远程服务器上的远程分支。

Git SCM 架构

面向 Rational Team Concert 用户的 Git 指南

面向 Rational Team Concert 用户的 Git 指南

表 1 定义和比较了两个源代码管理系统的组件。

Rational Team Concert 和 Git 的架构组件

比较架构和工件
Rational Team Concert Git 备注
存储库 存储库 两个系统中的主代码存储被称为存储库。在 Rational Team Concert 中,服务器仅保留存储库的完整副本。在 Git 中,每个用户都创建整个存储库的一个本地克隆版本。
沙箱 工作树 开发人员签出的本地文件和尚未签入 / 提交的本地更改。
分支 共享的代码行在 Rational Team Concert 中称为 ,在 Git 中称为 分支 。一个简单的工作流有且仅有一个集成流或分支。在 Git 中,此分支的默认名称为 主分支
存储库工作区 特性分支(远程) 实质上,Rational Team Concert 存储库工作区是一个存储在中央服务器上的个人分支。Git 用户对分支的使用更为广泛。例如,您可以创建一个分支来支持某项特性,然后在将该特性合并到一个集成分支中后删除该分支。Git 拥有本地和远程分支,每个本地分支都 “跟踪” 到一个远程分支。
不适用 特性分支(本地) Git 支持的离线开发场景比 Rational Team Concert 更多。Git 用户可通过本地提交操作将更改提交到任何分支,然后在离线工作时将更改推送到其远程分支。
组件 不适用 Rational Team Concert 支持通过组件对流中的代码进行逻辑分离。Git 没有与组件对应的概念。Git 用户倾向于将其开发工作分解到多个存储库。
基准 / 快照 标签 基准、快照和标签标记一个已知的代码级别,是以后创建分支的启动点。举例而言,可以创建这些工件来标记 “release 1.0”。
更改集(活动) 暂存更改 一个包含一个或多个工件更改的可变集合。
更改集(完成) 提交 一个包含一个或多个更改的不可变集合。

比较命令和概念

Rational Team Concert 和 Git 的命令集非常相似。关键区别在于,Rational Team Concert 中的源代码管理采用集中管理方法,而在 Git 中,管理工作被分散到服务器存储库和本地克隆版本中。

在图 3 中,Rational Team Concert 用户通过签入将代码从其 Eclipse 工作区转移到存储库工作区,然后使用交付操作将代码从存储库工作区转移到远程流。接受操作将更改同时转移到存储工作区和 Eclipse 工作区。

Rational Team Concert 中的命令流

面向 Rational Team Concert 用户的 Git 指南

面向 Rational Team Concert 用户的 Git 指南

图 4 展示了将代码转移到一个共享的团队分支所需执行的多个步骤。在此场景中,开发人员将更改从其工作树添加到暂存区域,将更改提交到本地分支,将更改推送到远程分支,最后合并到团队分支。拉入操作将更改从一个分支一直转移到一个工作树。

Git 中的一个命令流

面向 Rational Team Concert 用户的 Git 指南

面向 Rational Team Concert 用户的 Git 指南

表 2 定义并比较了 Rational Team Concert 和 Git 中的关键命令。

Rational Team Concert 和 Git 中的关键命令

比较 Rational Team Concert 和 Git 命令
Rational Team Concert Git 备注
签入 添加 在本地工作副本中准备将要在上游集成的更改。在 Rational Team Concert 中,此操作将更改发送到服务器进行安全保护。在 Git 中,它将更改发送到本地暂存区域。
交付 推送 / 合并 Rational Team Concert 用户将来自其存储库工作区的代码集成到一个流中。如果需要一次合并,则会阻止交付。Git 用户通常首先通过推送操作将代码交付到远程分支(称为 特性分支 )。在一个不同操作中,它们将此分支合并到一个主要集成分支(也称为 主分支 )。如果合并将需要手动干预,Git 会阻止合并,直到用户解决任何冲突。
注释 / 显示历史 日志 两个系统都提供了所有文件或所有提交内的更改的完整可跟踪性。
加载 克隆 从主存储库将源代码下载到本地工作站。Rational Team Concert 提供了部分加载存储库的能力。
接受 拉入 从主存储库上的活动分支将更改下载到本地工作区域。Rational Team Concert 的接受操作从用户连接到的流拉入所有更改。Git 的拉入操作与接受操作直接对应,它将更改从一个分支拉到另一个分支中(例如从远程分支拉到本地分支)。
不适用 抓取 从用户跟踪的所有远程分支将更改下载到其本地存储库克隆版本。用户从该分支执行拉入操作之前,抓取 不会 将用户的任何本地分支升级到该远程分支的状态。
锁定 / 解锁 不适用 锁定会阻止其他用户修改文件。Git 没有这种机制。
放弃(活动更改集) 取消暂存 在 Rational Team Concert 中,此命令从存储库工作区和本地沙箱删除更改。在 Git 中,它仅从本地分支删除更改,保持工作树原封不动。
放弃(已完成更改集) 重置 更新本地状态,就像给定更改从未下载一样。在 Rational Team Concert 中,如果向状态中引入了空白,将阻止放弃操作。Git 为其重置操作提供了多个选项。 reset—hard 大体相当于 Rational Team Concert 放弃操作。
状态(未决更改) 状态 两个工具都允许您通过多种方式对本地状态与远程状态进行比较。
更改您的流目标 签出 切换到不同的开发线,例如在一个维护分支上工作而不是进行主线开发。
创建快照 创建标签 使用已知标识符标记存储库的状态(例如 “Release 1.0”)
创建存储库工作区 / 流 创建分支 创建一个新开发线 / 集成点。
暂停 存放 将存储库工作区和工作树恢复到执行暂停的更改之前的状态。在 Rational Team Concert 中,暂停的更改集存储在服务器上,可归入同一个用户拥有的一个不同的存储库工作区。在 Git 中,存放完全在本地执行。
恢复 Git stash apply 暂停 / 存放 的相反操作;此命令将暂停或存放的更改应用于用户的工作区域。
反转 复原 创建一个与相关更改 “相反” 的更改集。有效地撤销相关更改。

理解 Git 场景

Rational Team Concert 和 Git 中的使用模式代表着两种根本不同的源代码管理哲学和方法。尽管开发人员倾向于在每个开发场景中以相同方式使用 Rational Team Concert(得益于它的可预测性和均匀性),Git 用户遵循且适应各种各样的使用模式。迁移到 Git 的一个重要方面是,确定哪些模式(或 Git 用语中的 )适合您的项目需求。

GitHub Flow 和 Git Flow 是两种最常用的 Git 模式,所以这里将看看每种模式的特征。考虑如何实现 Rational Team Concert 中的模式才有助于您在使用 Git 时采用它们。

GitHub Flow

GitHub Flow 是一个使用相对短期分支为基础的源代码控制模式,其中每个分支表示一个特定的开发或其他某个小工作单元。当该工作单元完成且所有测试都通过时,分支所有者将该分支合并到主分支,然后删除与该工作单元关联的分支。

如果想要在 Rational Team Concert 中实现此模式,需要先根据集成流创建一个新 “特性” 流,然后将一个或多个存储库工作流传输到它,直到开发完成。然后可以将这些存储库工作区中的一个传输到集成流,并一次交付所有更改。(回想一下,Rational Team Concert 不允许直接的流间交付。)在 Rational Team Concert 和 Git 中,如果一次合并冲突会阻止代码集成,您会收到警告。在这种情况下,系统会提示您解决合并问题。

Git Flow

Git Flow 基于 Vincent Driessen 开发的 “ 一个成功的分支模型 ”。像 GitHub Flow 一样,它使用从一个共享开发分支分叉出来的短期特性分支。主要区别是它对发布候选版使用了不同的分支,而且不会频繁地交付到主分支。

要与 Git Flow 建立大体对应关系,在 Rational Team Concert 中,您可以使用 “ 如何保持在 Rational Team Concert 中顺利传输流 ” 中列出的技术。在本例中,您的团队将为每日开发设置一个要合并形成的集成流,就像在 GitHub Flow 中所做的那样。然后,您可以使用一个 “发布候选版” 构建流程将集成流升级到发布候选流。接受发布候选版后,您的团队可以设置一个类似的编译版来将发布候选流升级到主流,最好使用快照标签,比如 Release 1.0。

因为 Rational Team Concert 允许您从任何给定快照快速创建流,所以您可以在 Rational Team Concert 中实现此模式的轻量型版本。您只需要小心地管理 Git 通常用来创建新分支的流位置上的流快照。

从 Rational Team Concert 迁移到 Git

切换到新开发工具通常需要进行一些调整。我们发现,以下流程更改支持更顺利地从 Rational Team Concert 迁移到 Git:

  • 使用短期分支 。Git 流最适合包含较小工作批次的短期特性分支。Rational Team Concert 中的流可能是长期的,开发人员通常会交付较大的批次。短期、专注的流支持通过拉入请求更轻松地审核代码,而且更容易供其他开发人员合并。保持您的 Git 分支关注点紧凑,而不是一次交付太多代码。
  • 经常提交 。在 Rational Team Concert 中,交付的更改被分发给每个人。开发人员倾向于更长时间保留代码,以确保它在交付之前完全就绪。Git 的理念是鼓励频繁的分支,即使是简单的特性。Git 一般提交到个人分支,所以在您与主分支合并之前,您的代码不会影响其他任何用户。通过经常提交,您会留下所完成工作的详细的可审计线索。这有助于更好地完成代码审核,因为您对已更新的内容进行了说明。团队成员也能查看所有远程分支,这使他们能够轻松查看每个团队成员的工作内容,实现更有效的全团队协同配合。
  • 使用多个分支 。不要害怕一次打开多个分支。在 Rational Team Concert 中,可以将一个工作区域(沙箱)关联到一个存储库工作区,而 Git 允许轻松地将沙箱关联到任意多个分支。这有助于保持您的分支小而专注。通过采用多个分支,一次处理多个代码区域。当您交付时,您的代码审核工作将通过每个特定任务的分支限制到该任务。

结束语

本文是为那些习惯使用 Rational Team Concert 且想要进一步了解 Git 的开发人员而编写的。若想成功地将您的工作流从 Rational Team Concert 调整为 Git,需要以不同方式思考如何管理和分发代码。我们的目标是帮助您理解两个源代码控制系统之间的原理、架构和命令结构差异。要更深入了解每个工具的具体功能,请参阅下面的参考资料。

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址