第六诫：你必须自己提交你的更改内容——不能委托他人 听起来很奇怪，但它的确会发生，我看过不止一次，最近的是上周。情况是这样的，源代码库被视为极高的地位。因为很多原因，团队会去追求完美代码的洁 净和单一。为了保持这种神圣的状态，代码只能由某个领头的程序员来提交，他在提交前会小心地整合，审查并（大概会）调整改善代码。 即使站在很远也能很容易评价这个方案。不太频繁的提交（可能一周几次），只有一个脱离团队其他程序员的人来提交，而且不可避免地在这段漫长的无提交时期里会有人的工作会导致项目混乱。非常非常不好。 这样做会有两个错误：首先，源代码管理软件并不意味着它里面代码是神圣不可侵犯的；至少在整个开发周期里是这样的。它应该是团队频繁整合文件，在出错时还原到正常并且共同解决问题的地方。不是自始至终都要这样做，只有在应用程序周期的发布时期为了达到某种状态时才做的。 另一个问题——并且真的是极为关键的——站在程序员的视角，这样等于你压根没有在用源代码管理软件！它等于没有同伴之间的代码整合，没有还原，提交信息没有负责人，什么都没有！你们仅仅是在自己的象牙塔里各自写各自的代码然后等着未来顺便某一天把它交给领导就完事了。 不要这样做。千万不要。 第七诫：一定要管理好数据库的版本
这一点是我们都知道必须要做的，但是很多人觉得它麻烦。问题是很多（或者是大部分）应用程序没了数据库就不能运行。如果你没有管理好数据库，那你实际上做的就是一个不完整的完全无用的应用程序。 几乎所有的版本控制系统的工作就是管理好文件系统内的文件。它只是对像HTML页面，图片，CSS，项目配置文件和其他在文件系统的独立单元这类典 型应用作用较大。问题是它确实没法在与程序有关联的数据库上起到作用。你总不能替换掉庞大的数据库，把所有旧数据文件和包含一大堆对象和数据日志文件统统 换掉。这样会让版本控制系统完全乱成一堆。 Red Gate公司开发的智能的SQL Source Control使这个情况得到了合理解决。我在去年写的Rocking your SQL Source Control world with Red Gate这篇帖子里详细说明了这款软件，所以我现在就不多说了；总之就是数据库管理现在会非常容易了！ 老实说，如果你没有管理好你的数据库版本，你的开发会伴随着很大的问题。在更改数据库的时候没有源代码的管理，没有还原点，并且很难和团队密切合作。使用数据库版本控制系统可以使开发更轻松。 第八诫：编译生成的文件不要放进源代码管理软件里 简单地说：在编译运行项目时自动生成的结果文件不要放进源代码管理软件里。对于.Net开发的程序员，主要是"bin"和"obj"文件夹里通常会出现的.dll和.pdb文件。 为什么？因为如果你这样做，你的同事会恨你的。这意味着每当他们从版本控制系统里取下最新文件时会让你的编译文件覆盖掉他们的。这是一个双重噩梦 （你绝不能这样做），在他们下一次编译时就会出问题。而且只要他们重新编译后再把编译文件重新上传上去，同样的问题会以相反的方向再发生一次，不过这次你 是受害者。你肯定不想这样的。 当然另一个问题就是这样做很浪费。这会浪费源代码管理服务器的硬盘空间，会浪费带宽并会通过网络发送时一直潜伏着，而且这样做造成的不可避免的冲突会极度浪费你的时间。 所以我们继续使用之前提到的“忽略”方案。只要把像"bin"和"obj"这样的路径直接忽略掉，一切就真的很轻松了。只要按照这种方法做一次，所有人都会感到开心的。 其实我在写pre-commit hooks时就说到了在版本控制的服务器上不能提交此类文件。当然如果有值得这么做的原因的话，只有这种情况下你可以上传。不过我倾向于不要这么做以免将来会导致某个人在更新时发生冲突。 第九诫：不要上传你自己的用户设置 老实说，我认为很多人没有注意到他们把自己的私人设置文件上传到源代码管理软件里了。这样会出现的问题是：许多工具会产生只管理你自己本地配置的文 件。它们只对你有用而且通常和其他人的私人设置文件相异。如果你把它们上传到源代码管理软件里，很快你就会覆盖掉其他人的私人设置文件。这样并不好。 这是一个典型的.NET程序的例子：
假如你没有立刻清理的话，多余出来的就是扩展文件和类型描述，也就是.ReSharper.user文件和.suo（Solution User Option， 解决方案用户选项）两个文件，它们只属于你，对其他人无效。 为了理解这点，我们来看看ReSharper文件：
在这个例子里，仅仅是在用户文件里记录了我启动了解决方案分析功能。这只是针对我，我喜欢这个功能，其他人则不一定。通常因为他们用的是老化的便宜的机子，我有点跑题了。关键是我的设置会强制让其他人也执行。我这么做不代表其他人也要这么做。 旁注：VSS不完美的地方主要在于ignoring .ReSharper.user files is a bit of a problem。可以看看这篇帖子。 这个原理同样也适用于.suo文件。不过这里看不到里面的内容（它不是XML格式，而是二进制），这个文件记录了解决方案浏览器的状态，发布设置和其他一些你不让强制用在其他人电脑的东西。 所以我们要再次使用忽略方案来处理。前提你现在用的不是VSS。 第十诫：附属文件也要集成在一起
这是十诫中的最后一条也是最最重要的一条。当应用程序需要外部的附属文件存在才可以正常运行的话，把那些文件也都放进源代码管理软件里！人们倾向于犯的错误是，在他们拥有自己设置文件和本地附属文件的环境里一切都表现得很好就把东西都上传了，之后觉得没问题了就不管了。但是其他人不能从源代码库里找到同样的附属文件的话，所有东西都会悲剧性地报错。 我想到这点是因为今天从源代码库里拖出某个旧项目并运行它时出现了这样的画面：
我以为NUnit一直在机器上，但这次没有。幸运的是使用NuGet可以快速解决问题，但是没有附属文件的话，不是每次都可以用同样的方式就能轻松解决的。有些情况下，它们并不是公开的，你很难全部都获取到。 我从源代码管理软件里取出的项目运行时之所以会报错是因为我发现"C:\Program Files..."路径下丢失了附属的文件。我花了不少时间用来联系最后更改过它的那个人（很明显他在世界上另一个很远的地方），获取了那个文件，把它放 进"Libraries"文件夹下并把它上传到了版本控制系统里，这样下一个提取文件的人就不需要再这么麻烦了。 当然另一个重要的原因是，如果你在任何一种集成环境里工作时，你的构建服务器不一定安装了那些库。你必须有那些文件才能运行。Doug Rathbone最近写了一篇很好的关于这点的文章Third party tools live in your source control(源代码管理软件里的第三方工具)。并不是非要那样做（我们也善意地评价了效果），不过它确实是一个很方便的建议。 因此推荐每个人第一天就把程序运行所需要的东西全都放进版本控制系统里。 总结 没有哪一条是很难理解的。老实说，它们都很基础：尽快并频繁地提交，确认你提交的东西改了什么，还有东西一定要放进版本控制系统里，解释清楚你的提交信息和确保是你自己提交的，不要忘记数据库和不要忘记附属文件。还有就是不要使用VSS:) 英文出自：Troyhunt译文出自：图灵社区 |
