TFS代码签入指导

2014-05-08 21:10 Franz 阅读(1868) 评论(0) 编辑收藏举报

1. 如果文件没有被放入到TFS中, 那么它是不存在的.

这一点是最好被理解的, 如果你的代码没有被签入到代码管理中,那么就不可能被团队的其他人获取的得到. 具体如何将文件纳入到TFS中请参考 Placing Files under Version Control

TFS的命名,约定跟限制请参考: Naming Syntax, Conventions, and Limitations

2. 尽早尽快提交, 但是别分裂提交.(Commit early, commit often and don’t spare the horses)

尽早尽快提交的好处是,减少你跟其人代码冲突的风险,合并的恶梦是随时间持续增长的. 试想一下,你迁出一个工程修改半个月后再签入,你要签入的代码跟代码库中已经大不相同了, 那么这个合并操作是否会让你抓狂呢.

每个提交要求当后续发生回滚时都能到达一个正确的位置. 智者千虑必有一失,如果你将事情搞砸了, 最后的保障是我们可以回滚到最近的一次变化. 但是如果你上次提交是残缺的,那么是将事情彻底搞砸了.

能做到当前这一点,还会带来一些额外的好处,就是它会迫使你分离出独立的工作单元, 而独立的工作单元是可以单独可执行的,也就迫使你更清楚的划分自己开发的功能模块.

3. 提交前检查的提交的内容, 必要的时候时候好代码比较工具.

点击Check In按钮是非常容易的, 这种便捷性可能会导致不相干的(或者原本不想签入的)文件被一同签入到了一个ChangeSet中. 设想一下,你修改bug的过程中临时修改了一下config文件中的连接字符串,最终被一同提交到了TFS中, 另一个人会在下一次获取时会获取到你临时设定的config文件. 解决这个问题的办法是简单的: 在签入代码前一定要记得看一下提交内容是否是你预期的(什么, 文件太多了看不过来?, 请参看第二步 ).

通常不需要签入的文件有: 二进制文件. 压缩文件. IDE配置文件. 日志文件. 缓存文件. 多媒体文件. 临时文件.

通常需要签入的文件有: 代码文件. XML文件. CSS文件. Sql文件. 文本文件.

4. 提交代码时别忘了留下点踪迹. 但是别写到此一游的废注释.

提交注释的作用是解释为何你要提交当前代码(提交的代码解决了什么问题). 代码写足够好可以不写注释,而签入的时候在你没有找到理由前请一定要写注释.

注释格式上建议是: 首行简短的描述当前更新解决的问题, 如果有bugId或者TaskId一定要记得带上去. 第二行,解释你做了哪些更新. 第三行解释为何要做这样的更新. 第四行,其它你还想说明的信息.

好的注释是非常难拿捏的,因为判别标准在读注释的人手里. 我们能做到的最低标准是不要说废话. 常见的废话注释: 1. 修复bug 2. 更新代码 3. 修正一处异常处理等等. 更多有意思的注释请参看What is the best comment in source code you have ever encountered?

5. 代码管理工具不是备份工具.

备份工具的目的是容灾, 代码管理工具注重的是代码管理, 当然它的确有一定的备份作用, 但这不是主要功能. 我们更多的是Check-In, Check-Out, Lable, Branch, Merge.

6. 代码管理不限语言. 不管你使用什么语言在进行开发都要纳入代码管理, 包括SQL,Obj-C

代码管理工具想要跟各个开发环境做到良好的配合是非常困难的, 但是TFS做到了这一点. Team Explorer Everywhere for Team Foundation Server工具运行你跨平台使用TFS. 这样就可以方便的管理其他平台的代码了.

Sql数据库版本控制可以使用 Redgate Sql Source Control 来进行源码控制.

7. 没人在乎你的本地配置

VS下常见本地配置文件有.ReSharper.user(Reshaper的配置文件)跟.suo (Solution User Options). 管理员通常会将这些文件忽略掉, 但是请不要手工的添加到代码中, 因为别人并不需要你配置文件, 除非你的目的是团队共享(举例来说:Settings.StyleCop文件是用于规范团队代码的配置文件,这样的文件被大家共享是有意义的).

8. 编译输出不要纳入源码控制, 但是软件发布是.

VS下代码编译出来的文件默认是不会被签入到TFS中的, 如果你配置了T4来输出一些文件,可能就难以幸免了. 通过(under Team -> Team Project Settings -> Source Control… -> Check-in Policy)可以特殊忽略一些文件防止被意外签入.

并不是所有的编译输出都不需要我们维护. 当对外发布一个版本时,避免每次要定位到当时环境再编译生成的麻烦问题, 通常我们会将线上发布的文件也加入TFS源码管理中.

9. 考虑好代码依赖项. 你能断定别人另一台机器上能正常编译么

编写代码时第三方依赖是非常麻烦的问题, 通常我们很难将依赖项完全纳入TFS管理中(比如某组件写日志部分依赖Nlog). 以前我们的做法是要求团队将TFS放入到统一目录层次下, 并将第三方的依赖也一并打包到某目录下. 在这样运作中发现大量的第三方依赖以及起版本管理是非常麻烦的一件事情. 此时Nuget横空出世算是解决了这个问题. 整个团队将自己产生的组件发布到内部的Nuget服务器上, 如果依赖第三方开源类库,那么就直接用Nuget官网来管理就好了.