目录
1. 使用TFS进行源代码管理
2. 如果代码没放在源代码管理软件里，等于它不存在
3. 要早提交，常提交，并且不要觉得麻烦
4. 提交前要检查你更改了什么
5. 写提交信息时一定要认真
6. 使用代码审阅提高代码质量
7. 一定要管理好数据库的版本
8. 将必要的附属文件集成到源代码管理
TFS具体使用请参考此链接：http://msdn.microsoft.com/zh-cn/library/ms181382.aspx
源代码管理软件是我们工作的必备工具，是许多开发团队的血液。那么如何更好的利用TFS进行源代码管理呢？
1. 为什么使用TFS 2012进行源代码管理
为什么使用TFS，从源代码管理方面来说，TFS具有以下优势：
l 与Visual Studio无缝结合，方便开发者进行源代码管理
l 支持代码审阅与讨论
l 支持邮件通知
l 支持Web访问与管理
l 支持工作项以及BUG等管理
l 不会上传.NET开发时生成的垃圾文件
l 自带版本合并以及比较工具。
l 支持数据库版本管理
l 自带很多管理工具（测试管理器、反馈客户端、界面设计工具等等）
2. 如果代码没放在源代码管理软件里，等于它不存在
每天重复读这句话——“使用源代码管理软件是唯一的有效措施”。除非你在工作时使用项目的源代码管理库来控制代码版本——否则代码等于没有存在过。
显然你曾发觉在你的本地机器上运行良好的代码在其他人那里运行的效果并不理想。是不是？他们不能获取你的最新版本，他们没法去归并代码文件，你没有正确地部署它（参考 you're deploying it wrong）而且如果你的 SSD 硬盘坏了的话你将永远地失去你的劳动成果。
只要你保持这个心态——代码只有提交后才是真的安全，才是其他良好编程习惯的保障。你可以把你的任务划分成许多很小的单元以便你逐一提交。你需要频繁地这么做。你就不必担心你的硬件会不会出棘手问题。
不过更重要的意义是（至少对于你的团队领导来说），通过源代码管理软件可以看到你做了什么。使用图表并列出项目清单是个好方法，不过怎么知道他们实际上在做些什么？而使用源代码管理软件进行工作就能看得一清二楚了。
3. 要早提交，常提交，并且不要觉得麻烦
关于前面那点，避免“幻影代码”（就是只能在你的机器上看到的代码）的唯一方法是经常提交你的任务并且不要觉得麻烦。它可以解决你的问题，不过这样做也会对你的工作产生其他的影响：
1. 每个提交的修订都会为你提供一个还原点。如果你完全把代码搞砸了（没骗你，我们都这么做过），你是希望恢复到一个小时前的工作还是一周前的工作？
2. 归并文件时会出现的危险会随着时间不断增加。归并文件一直很麻烦。如果你不是每天都保持提交代码，某一天你会突然发现你和其他人的更改内容会有 50 多个冲突。你不会为此感到高兴的。
3. 它促使你把任务分离成分散的单元。通常人们都是快完成的时候才提交的，因为他们想把代码做成一个完整的逻辑单元模块。不过庞大的任务不可避免地要分离出较小的分散功能，而频繁地提交它们会使你更了解它们，你可以一个个地构建并提交。
如果你做到这些，你的提交历史不可避免地开始类似于一种半规律的样式，里面每个工作日都是在提交任务。当然不总是这样，也有停下来重构或测试，或者其他合理的活动也会中断标准的开发周期。
然而，当我在看一个独立的——尤其是完整的项目时，每当发现我们在一个标准的开发周期里，有一天或几天什么都没有做，我便会非常担忧。我之所以担忧是因为这意味着什么地方出问题了。一般不是有人正在想方设法要把问题搞定的话，就是因为卡在某个问题上而导致项目完全没有进度。无论到底是什么情况，源代码管理软件都会告诉你出现问题了。
4. 提交前要检查你更改了什么
往源代码管理软件里提交代码的步骤其实非常简单。（你恐怕会困惑上一条为什么说的那么麻烦。）一般只要发现文件内容有变更时都会不顾后果地把文件传上去。像这样——“我的项目根目录下有文件内容变更了，我要快点提交上去！”
如此会发生一件（或两件）事情：首先，程序员会没有意识地把目录下的垃圾代码文件也上传上去。一些人看到类似下面的SVN提交窗口时，就会点击“选择全部”然后提交——这样源仓库里就会被本不应该存在的未调试的文件和其他垃圾文件给弄乱。
或者是，程序员实际上并没有检查他们更改过什么就把文件上传了。当你在工作中处理配置文件或项目定义文件时很容易就不经意把那些不想提交的文件给上传了，而且那些文件很可能就被别的程序员用到了。
5. 写提交信息时一定要认真
这是一个古老的谚语（出处不详），大意是说“写每一条提交信息时就好象等下会读到它的人是一个斧头杀人狂，而且他还知道你住在哪里”。如果我是那个杀人狂并在研究你的代码想追踪 bug 的话，看到的提交信息全部都是“代码更新了”，小心，我会来砍你的！
我的解决办法就是解释清楚为什么要提交新的代码。每次你对代码进行更改都是有原因的。可能什么地方会崩溃。可能客户不喜欢现在的主题颜色。可能你仅仅要调整一下构建配置。无论是什么，这都是有原因的而且你要把原因用文字保留下来。
为什么？这样做的原因有很多，而且在不同环境下各不相同。举个例子，使用“历史记录”特性或其他类似的功能显示出谁改了代码那些地方。如图：
这是一个可以随时观察代码更改的软件的一种。无论我想了解一个文件的完整更改历史，还是只想知道团队昨天做了什么，留下一个描述性的相关记录意味着只要不经意一瞥就能知道是什么情况了。
6. 使用代码审阅提高代码质量
代码审阅可以提高代码质量。
Visual Studio2012包含了源自于Team Foundation Server的代码审阅工作流。具体使用请参考此链接：http://msdn.microsoft.com/zh-cn/library/hh474795.aspx#code-review-request
7. 一定要管理好数据库的版本
这一点是我们都知道必须要做的，但是很多人觉得它麻烦。问题是很多（或者是大部分）应用程序没了数据库就不能运行。如果你没有管理好数据库，那你实际上做的就是一个不完整的完全无用的应用程序。
老实说，如果你没有管理好你的数据库版本，你的开发会伴随着很大的问题。在更改数据库的时候没有源代码的管理，没有还原点，并且很难和团队密切合作。使用数据库版本控制系统可以使开发更轻松。
那么使用，Visual Studio的数据库项目来管理数据库，就能够利用TFS来管理数据库版本了。具体使用请参考此链接：http://msdn.microsoft.com/zh-cn/library/vstudio/dd193266(v=vs.100).aspx
使用VS数据库项目具有如下优点：
l 支持版本管理
l 便于团队协作开发
l 支持对不能版本数据库进行部署
l 支持生成测试数据
l 提供了许多额外的功能与工具：数据库架构比较、数据比较、生成脚本等
8. 将必要的附属文件集成到源代码管理
这是特别重要的一点。当应用程序需要外部的附属文件存在才可以正常运行的话，把那些文件也都放进源代码管理软件里！人们倾向于犯的错误是，在他们拥有自己设置文件和本地附属文件的环境里一切都表现得很好就把东西都上传了，之后觉得没问题了就不管了。但是其他人不能从源代码库里找到同样的附属文件的话，所有东西都会悲剧性地报错。
比如，通常我们的项目会引用很多第三方的dll，那么就应该将这些dll都集成到源代码管理，如图：
最后
- 本篇文档Word版下载地址：TFS源代码管理的8大注意事项.zip。
- 本文参考了《源代码管理十诫》，并做了一些修改。
- 希望大家积极讨论并补充。
博客转自：《TFS源代码管理的8大注意事项》