[转载]TFS源代码管理

以下主要描述了：

1. TFS源代码控制系统的基本场景
2. 如何把一个项目添加到源代码管理中
3. 如何与服务器同步
4. 如何做Check-In
5. 如何做分支与合并
6. 什么是上架与下架

我们知道工作项是项目管理的基本元素，但是一个项目的成功，光有工作项还是不够的。工作项说明了要做什么事(例如任务)，出了什么问题(例如Bug)，除此之外，我们还需要将程序一行一行地写出来，TFS的源代码管理控制系统，就能帮助我们管理这一行行的代码，一个个的文件，一次次的修改，直到产品发布。

1、TFS源代码控制系统的基本场景

这里介绍一下，如何在Visual Studio.net中使用源代码控制系统，我们知道Visual Studio IDE可以和Visual Source Safe等多种源代码控制系统集成，所以我们首先需要选择用什么来控制源代码，这可以通过从IDE菜单中选择“工具(Tools)”->“选项(Options)”，在选项对话框中，找到源代码管理（Source Control | Plug-in），然后选择Visual Studio Team Foundation Server:

2、如何把一个项目添加到源代码管理中

首先，我们需要有一个团队项目，下面我们以测试环境中已有的团队项目TFSTest为例进行说明，当我们把一个源代码项目添加到源代码管理系统中时，Visual Studio会为你创建一个工作空间（Workspace）。

一个工作空间是服务器的文件、目录在客户端的映射。当用户对源代码管理中的目标进行增加、编辑、删除、移动、重命名，或者其他操作时，用户的修改会保留在工作空间中，标记为工作空间中的“待定/未提交修改”(Pending Change)。这些修改只有被用户签入（Check In）后，服务器上的文件或目录才会跟着改变。

下面我们演示创建一个新的解决方案和项目，并将其添加到源代码管理中：

在Visual Studio IDE中，创建一个新的项目，选中“添加到源代码管理”（Add to Source Control）：

集成环境在后台开始创建项目的框架，然后会提示你，选择将新建项目添加到TFS上的哪个Team Project中，这里，我们选择TFSTest项目，点击确定：

然后，我们打开菜单“视图”->“其他窗口”->“源代码管理资源管理器”：

就可以看到新添加到TFSTest团队项目下的ITRequestFormPrj1了：

项目文件夹前面是一个黄色的+号，代表这些都是Pending Change.

如果我们需要把现有的解决方案，或者项目添加到TFS中，那么可以打开这些解决方案或者项目，然后右键点击解决方案，选择“将解决方案添加到源代码管理”：

然后在弹出的窗口中，选择将解决方案添加到那个Team Project中。

现在我们试着编译一下项目（模拟一下验证代码的正确性），然后就将这些Pending Change 签入到TFS中，选择“视图”->“其他窗口”->“挂起的更改”：

就可以看到目前有哪些Pending Change：

然后点击签入按钮，所有被选中的Pending Change文件都会被签入。

下面我们看看，如果向已经加入源代码管理的项目中，添加一个文件，会是什么情况：

• 首先，项目会被自动Check-Out（签出），在项目前面有一个红色的打钩图标(下面左图)
• 其次，新增的文件前面有一个黄色的+号，表示这是一个挂起修改的文件（下面右图）

先把Class1文件签入，然后我们试着双击打开Class1.cs文件，输入一行注释，我们发现编辑文件后，文件会被自动签出（Check-Out），由于文件被Check-Out，所以项目的状态也更新成Check-Out了：

3、如何与服务器同步

在团队协同工作的环境中，许多人都在修改同一个项目中的代码，你需要把项目中最新的修改下载到本地。如下的操作，可以让你的工作空间和服务器上的最新版本同步：

• 在解决方案窗口中，选择项目或者整个解决方案，右键点击，选择“获取最新版本”

• 在源代码资源管理器中，选择一个Team Project，可以将该团队项目的最新版本同步到本地：

如果在上图中，选择一个Team Project下的某个解决方案文件夹，则可以针对某个解决方案获取最新的版本。

在签入你自己的代码前，最好把服务器上最新的版本同步下来，这个过程需要解决可能的版本冲突问题，然后你要构建项目，保证没有问题后，再签入代码。这是为了尽量避免你签入的代码，导致在服务器和其他开发人员的机器上出现构建失败。

4、如何做Check-In

以下三种方法都可以做签入（Check-In）

• 在解决方案窗口中，右键点击修改后的文件，然后选择签入

• 在源代码管理窗口中，右键点击修改后的文件，然后选择“签入挂起的修改”

• 在挂起的更改窗口中，选择要签入的文件后，点击签入按钮：

这种方法可以让我们做快速的签入，默认情况下，所有被修改的文件，都会自动列出，根据需要确定要签入的文件后，可以填写签入的注释，对签入的修改关联对应的工作项：

填写代码的相关审阅者：

查看签入是否已经满足预定的策略：

当用户选择签入后，所有选中的文件，签入说明，以及与此次签入相关联的工作项，都将被存储到数据库中，作为一个新的更改集（Changeset）。一个更改集是文件版本、相关工作项、以及源代码管理元数据（Metadata）组成的一个单独的实体。

如果工作项有相关的流程处理规则，这些规则会修改工作项的状态。例如，一个团队可能会定义如下规则：如果当你签入时管理了工作项，并选择“签入操作”为“解决”，则工作项会从“活动的”变为“解决”：

5、如何做分支与合并

TFS中支持分支的概念，所谓的分支（Branching），就是指把源代码控制系统中的文件和目录复制一份。分支能够保持文件和目录的历史，并且能够把旧的文件上的修改合并到新的文件上去。在新的分支上的修改，和原来的分支（一般称为主分支）没有任何关系。

合并（Merging）是指把不同分支中的文件（文件、目录、团队项目）合并到一起。在合并操作中，一个分支是源分支，另一个是目的分支。源分支中包括了用户想要合并的文件。

考虑下面这种情况：

在时间的要求下，我们可能要先发布一个版本，那么我们可以建立一个Release1的分支，然后主分支代码和分支代码同时继续开发。在某个时刻，可以将两个分支合并。

下面是分支应用的另一种场景：

在功能细分的要求下，例如Visual Studio就分成好多个版本:Express 版本、标准版本、企业版、架构师版等等。他们拥有共同的基础功能，在这部分功能开发完成后，可以通过分支来实现不同版本对应增值功能的开发，例如从主代码中分支出功能A、功能B

也有可能这些增值功能不是必须的，如果可以实现，我们就合并到主代码中，如果不能实现，则取消合并。

通过上述的场景，可以看到分支为代码管理提供了更佳的灵活性。

5.1创建分支操作演示

在Visual Studio中进行分支操作，十分方便，首先我们创建一个分支：

• 在源代码管理器窗口中，选中一个要对其进行分支的项目，例如下图的ITRequestFormPrj1，然后右键点击选择“分支”：

• 在这里，可以选择分支的名称、对主分支的最新版本还是指定版本进行分支，是否创建新分支的本地副本（也就是将新分支从TFS服务器上下载到本地工作区中）

• 点击确定按钮后，开始创建分支的操作，创建成功后，我们在源代码管理器窗口中，可以看到主分支和新分支之间有一个双向箭头的图标表示了它们的关系：

5.1合并分支操作演示

我们先试着在新的分支中修改一下代码，然后签入修改，接下来我们演示合并分支的操作：

• 在源代码管理器窗口中，选择一个分支，将其合并到主分支，右键点击后，选择“合并”：

• 在源代码管理合并向导中，选中的分支作为源分支，目标分支会自动被识别出来：

• 在上图中，点击下一步按钮，向导会提示你，选择源分支的哪个版本进行合并：

• 确定以后，向导提示你可能需要解决冲突：

点击完成按钮，如果合并的分支之间有冲突，则会提示你要先解决冲突后，才能合并：

点击解决按钮，提示Form1.cs文件存在冲突：

点击比较按钮，在比较窗口中，会显示两个分支中，同一个文件的差异：

在上一个窗口中，选择“在合并工具中合并修改”，并点击确定按钮：

后台会为你启动合并工具，需要稍等片刻：

在合并工具中，可以选择一边的更改加以应用，如果有多个不一致的地方，则可以通过“上一个更改”和“下一个更改”进行方便的导航：

选择一个更改的内容后，你还可以在最下面的编辑窗口中，进行最后的修改，然后点击确定即可：

提示冲突已经解决，是否保存文件，点击是：

当所有冲突都已经解决后，点击关闭，退出冲突处理，完成合并操作：

这个时候，我们打开合并的目标分支，因为修改的内容合并到了目标分支，目标分支的对应文件处于挂起的更改“合并，编辑”，需要对其进行签入操作，才能将最新的内容提交到TFS服务器上：

6、什么是上架与下架

上架（Shelve）和下架（UnShelve）命令听起来不容易理解。我们不妨相像一下，你正在办公桌上伏案画图，假设是用工笔画红楼梦群芳夜宴图，大大小小的美女草图铺满了桌面，这是你接到命令要做另外一件事：泼墨画，而你只有一个办公桌，万一泼墨到美女们怎么办?于是你就把目前的所有图纸卷起来，放到书架上。这就相当于上架。

接下来你开始泼墨画的工作。尽情挥洒之后，清理桌面，从书架上把刚才收起的图纸都拿下来，铺开，继续你的群芳夜宴图。这就相当于下架。

这两个命令主要用于：

• 保存目前的工作，切换到另一个任务
• 其他人开始代码复审（你将修改上架了，别人可以在自己的环境中，把你上架的内容下架，然后做复审）
• 集成别人的修改（两人的修改互相依赖，这是可以通过上架/下架命令把修改集成起来）

这位多人协作提供一种便利：不需要每次Check-In，然后别人Check-Out，而是多次上架下架后，最后来一次Check-In即可。

上架的操作十分类似于签入操作，在源代码管理器中，右键点击要上架的文件，选择“搁置挂起的更改”即可：

所有的参数都与签入操作类似，不同的是，修改不会做冲突检查，也不会影响源代码（即没有真正被Check-In，这可以在上架操作结束后，验证文件前面还有红色打钩标志来确认），而是暂时存储在TFS服务器上，以便其他人做下架处理：

转自博客：《TFS下的源代码控制 》