一个优秀的配置管理流程

使用一个或多个CM服务器进行数据备份，以防止数据的丢失。根据不同CM工具的存储方式，数据以层级式或者数据库等的形式保存下来。

版本升级. 当一个人独立完成工作的时候，软件开发中的每一个重要步骤都必须保存下来。 CM工具可以方便的记录开发中的所有的里程碑。而多个人同时进行软件设计时，冲突就出现了。

Check-out, Check-in 和Merge notions

假设有两个设计者同时进行主要的开发工作：

• 从自己的CM客户端向CM服务器提出请求，要对f文件进行修改，这一操作就是Check Out。
• 当你在修改f文件的内容时, 你的同事也需要修改同一文件。他通过自己的CM客户端，要求CM 服务器Check Out f文件. CM服务器就会阻止他对f文件进行编辑（因为你已经在使用她），或者警告你的同事，其他人正在使用该文件（我们假设你的同事成功的check out 了f 文件）。
• 你完成后将修改的内容回传给服务器，这一操作就是Check In。
• 当你的同事完成了对f 文件的操作并试图回传修改后的版本，CM服务器会认为最新的版本并不是先前check out的版本，从而拒绝接受。此时要实现check in，就需要再增加一个步骤，那就是Merge（合并）:
  • CM工具提供了f文件的最新版本，借助CM客户端和其他CM工具，你需要将该版本与你的本地版本合并（merge）。
  • 有些CM工具能够实现自动合并（merge），从而为较简单的工程节约时间。但并不是每次都能奏效，同时你还必须指明是出自哪一个版本哪一个文件的哪个部分。
  • 因为我们经常会使用并非自己设计的软件，并且经常出现错误也是难免的，所以一个让人满意的优秀的分离/合并（diff/merge）工具就是非常重要的。
• 当合并（merge）的步骤完成以后，并验证得出(编译 + 回归测试)该合并运行良好，就可以进行 check in了，而f文件的最新版本则包括了你和你同事两人的修改内容。

配置管理下的软件分支

同一个软件可能会有许多版本。由于CM工具的不同，处理的方法也大相径庭，但有许多是通过分支的形式来实现的。

假设你专门开发了一个分支，叫做“trunk”，作为主要开发工作的核心部分。你可以新建一个分支或者发布一个详细版本，或者新建一个与现有开发工作互不干扰的模型。你可以在使用"trunk"的同时，通过CM服务器上对任何分支进行操作。

如果你需要把修改从一个分支传递到另一个分支（比如一个重要的bug修改），大多数的CM工具都可以通过上面提及的合并的过程来实现这一点。