本文通过几个软件开发过程中常见的却又有一些棘手的问题来介绍了 RTC Patch 功能的用法，展现了 RTC 中 Patch 功能灵活易用的特性。IBM Rational Team Concert（RTC）是 IBM 基于 Jazz 平台推出的一个商业产品。这是一个协作式的软件开发平台，项目开发团队能够通过 RTC 显著提高软件开发的效率和成本。
利用 Patch 撤销已经交付的变更集
变更集(Change Set)是 RTC 版本控制中的最小操作单位，用户可以对变更集进行接受(Accept)、交付(Deliver)、提交评审(Submit for review)等功能。开发人员经常会遇到的一个问题是当某个变更集交付之后因为某些原因想要撤销变更，这时可以有多种方法实现这一操作。除了利用快照恢复工作空间或者丢弃(Discard) 变更集以外，还可以使用一种更安全的方法，利用补丁回退变更集。
首先选择所需要回滚的变更集，右击，点击Reverse按钮，如图 1 所示。
图 1. Reverse 菜单项
这时，在 RTC 的客户端工具的 Pending Changes 视图的顶端生成一个与所选变更集反向的补丁(图 2)，即如果源变更集中源代码文件中为添加代码，那此处补丁变更文件则为删除代码；源变更集为删除操作，那此处补丁文件所包含的操作则为添加操作，依此类推。
图 2. Pending Patches 视图
此时，用户可以对该补丁项进行 Auto Resolve 操作以将此补丁加入到用户的本地改动中去。右击补丁，点击Auto Resolve…，在弹出的确认窗口中点击确认按钮。
图 3. Auto Resolve 菜单项
此时一个针对于该变更集的回滚改动就已经在本地工作空间中生成了。用户可以对该本地改动进行一些常规操作，比如检入到变更集或者做一些人工修改。当用户最终交付该变更集之后，一次回滚代码操作就全部完成了。如图 4 所示，由 patch 导入的本地改动就被引入到本地工作空间 sandbox。
图 4. 本地变动集合视图
利用 Patch 共享开发中的代码
共享代码在协同软件开发中有着举足轻重的地位。多个开发人员往往需要开发同一个软件功能，这时，共享代码就尤为重要。除了传统的交付和接受代码变更集以外，常常会出现这样一种情况: 程序员 A 正在编写的代码会被程序员 B 所依赖，但是程序员 A 的代码还没有完全完成，只开发了部分可用代码或者接口。程序员 B 因为 A 的代码还没有交付，所以无法进行下一步工作。这时，A 可以把一部分已经能够运行的初始版本共享给 B，以防止阻塞程序员 B 开发的情况发生。
通过 RTC 源代码控制的搜索功能，找到对应的变更集。在 Team Artifacts 视图中右击 源代码控制 (Source Control) ->搜索 (Search) ->变更集… (Change Sets…)
图 5. 搜索变更集菜单项
进入变更集搜索输入框，填写相应的查询条件，点击搜索按钮，弹出搜索变更集的对话框，如图 6 所示。
图 6. 搜索变更集对话框
下图为变更集查询结果样例，我们可以注意到变更集图标为三角形未打钩的表示该变更集还没有完成且尚未交付，如图 7 所示。
图 7. 变更集搜索结果
右击特定的变更集，新建 (New) -> 补丁… (Patch…)，创建一个新的补丁，如图 8 所示。
图 8. 新建补丁按钮
打开对话框(图 9)，选择补丁选项。除了选择需要创建补丁的源代码文件以外，还需要选择补丁文件的保存形式。此时，有两种方式可用于保存该补丁，
保存到剪贴板 保存到文件
图 9. 创建补丁对话框
此处我们可以选择保存到文件，点击确认按钮。保存完成后会在我们指定的位置生成.patch 文件。该文件可以用于后续的本地变更集生成。
在 RTC 主菜单中点击项目 (Project)->应用补丁… (Apply Patch...)，在打开的对话框(图 10)中选择刚才生成的.patch 文件，点击完成按钮。这样，一个新的补丁列表就会生成在 Pending Change 视图中。当用户选择自动解决 (Auto Resolve) 之后，该 Patch 就会合并到本地 sandbox。这样，程序员 B 就完成了把程序员 A 的代码融合到本地过程，一次代码共享过程就完成了。用户 A、B 可以持续的共享和协作开发，大大提高了软件系统开发效率。
图 10. 应用补丁对话框
利用 Patch 可以先交付依赖变更集中的后检入代码
当用户在使用 RTC 的时候常常会遇到这样一个问题，开发人员同时拥有多个变更集，前一个变更集已经完成(Complete)并且在 Review 状态，或者因为某些原因，暂时还不能交付。但是后一个变更集中的一些文件又和前一个变更集有共享文件。如图 11 所示，源代码文件 AdvanceOverrideDialog.js 被两个变更集包含。
图 11. 两个相互依赖的未交付变更集
当用户想要交付后一个变更集的时候，系统会提示用户该变更集不能交付(如图 12 所示)。这个时候可难办了，第一个变更集可能因为某些原因暂时还不能交付，且并没有确切的交付时间。难道程序员就只能一直等到前一个变更集能交付的时候，两个一起交付么？不，RTC 中的 Patch 功能能够帮你轻松解决这个问题。
图 12. 交付错误警告框
首先，用户分别对这两个变更集生成补丁文件，具体生成补丁的操作步骤同上。这时，在用户的本地已经有两个补丁文件了，这两个补丁文件分别包含了两个变更集中的各自的改动。 选中这两个变更集，右击点击丢弃(Discard…)，如图 13 所示。
图 13. 丢弃变更集
点击项目->应用补丁…，选择后一个变更集所对应的补丁文件 右击Pending Changes视图中的该补丁，选择Auto Resolve… 生成 unresolved 的本地改动，选中这些改动，右击点击检入->新的变更集。
至此，一个新的包含后检入代码的非依赖变更集已经生成，用户可以自由的对此变更集进行交付操作。而对于被依赖的前一个变更集的所有代码改动，因为都包含在补丁文件中。所以当下次有需要交付的时候，可以再应用该补丁，就能完整的把该补丁所包含的代码改动恢复到本地 sandbox 中。
利用 Patch 合并已完成变更集/合并 Merge 变更集到源变更集
软件开发过程中，一个 Story 或者一个 Task 往往会关联多个变更集，那些因为迭代开发或者因为功能点比较大而进行分批次的变更集交付我们是能够接受的。但是，有些情况下我们并不希望一个 Work Item 关联多个变更集，因为这样对我们追踪 Work Item 制造了一定的困扰。例如，用户在提交一个代码评审请求之后，这个变更集会自动的标记为完成(Completed)状态，但是在代码评审的过程中，需要对代码做一些改动或者优化是常见的现象，这时，开发者就不能在现有的变更集上进行改动，因为此时的变更集已经处于完成状态(Completed)。通常我们的做法是再创建一个变更集，用来更新那些代码评审中产生的所需要调整的代码。如果评审过程经历往复多次，那么，这一个任务将会关联多个变更集。使得在后期查看这些变更集的时候带来不必要的麻烦。
RTC 的 Patch 功能可以用来合并这些已经标记为完成的变更集。操作步骤如下：
首先，用户分别对这两个变更集生成补丁文件，具体生成补丁的操作步骤同上选中这两个变更集，右击点击 选中这两个变更集，右击点击丢弃(Discard…) 点击项目->应用补丁…，选择第一个变更集所对应的补丁文件 在暂挂的变更 (Pending Changes)视图中右击该补丁，选择Auto Resolve… 生成 unresolved 的本地改动，选中这些改动，右击点击检入->新的变更集 重复第 3 步，直到把所有补丁都应用到本地 sandbox
注意：在第五步的时候，后续的一些补丁在检入的时候可能会有一些文件冲突，如果在使用 RTC 自动解决冲突的时候可能依旧会有一些冲突(conflict)无法自动解决。此时需要用户人工解决冲突。
同理，在代码开发过程中，团队其他人员可能交付了同一个文件的改动。当用户准备交付时，系统解决冲突的时候会产生一个 Merged 变更集。如果用户想要合并这个 Merged 变更集到源变更集，也可以采用上述做法进行合并。
总结
本文通过几个在软件开发中版本控制常见的几个问题入手，详细介绍了使用 RTC 源代码控制的补丁功能。让用户熟悉和理解 RTC 补丁功能的运用。