若是还有可以毫无偏见地涉及各个编程语言，比源代码管理软件更必要的工具，我倒是很想见识一下。源代码管理软件是我们工作的必备工具，是许多开发团队的血液。那为什么我们都会对它有所误解呢？为什么都很难理解版本控制系统的核心价值和基本原理呢？ 我总结出10条惯例——如果你愿意也可以用“戒律”——意味着必须服从它而且从一开始很难去理解。它们与所有类型编程语言的版本控制软件都有关联。在这里我选取了Subversion和.NET的几个例子，不过它们也广泛地适用于其他的一些技术。 第一诫：如果你现在还在使用VSS－请立刻停手 它已经死了。当然不完全对，它也存活了许多年，被全新的更实用的源代码管理工具超越之后还在苟延残喘地活着。准确地说当微软几个月后不再为其提供支持时(还是会坚持一段时间的)，它才是真的死了。 平心而论，VSS还是一个不错的工具。在1995年，它的光芒被像Subversion这样类似于Git和Mercurial的分布式软件给遮盖住了。微软表示要取代它已经好多年了。 原因是因为不支持如今的标准所导致的一系列缺陷使它一直不被看好。众所周知它是微软的悲剧系统，但不知何故它能坚持这么久，尽管它有那么多小故障，缺陷，并且不包含必需的功能（相对于今天的标准）。
第二诫：如果代码没放在源代码管理软件里，等于它不存在 每天重复读这句话——“使用源代码管理软件是唯一的有效措施”。除非你在工作时使用项目的源代码管理库来控制代码版本——否则代码等于没有存在过。 显然你曾发觉在你的本地机器上运行良好的代码在其他人那里运行的效果并不理想。是不是？他们不能获取你的最新版本，他们没法去归并代码文件，你没有正确地部署它（参考you're deploying it wrong）而且如果你的SSD硬盘坏了的话你将永远地失去你的劳动成果。 只要你保持这个心态——代码只有提交后才是真的安全，才是其他良好编程习惯的保障。你可以把你的任务划分成许多很小的单元以便你逐一提交。你需要频繁地这么做。你就不必担心你的硬件会不会出棘手问题。 不过更重要的意义是（至少对于你的团队领导来说），通过源代码管理软件可以看到你做了什么。使用图表并列出项目清单是个好方法，不过怎么知道他们实际上在做些什么？而使用源代码管理软件进行工作就能看得一清二楚了。 第三诫：要早提交，常提交，并且不要觉得麻烦 关于前面那点，避免“幻影代码”（就是只能在你的机器上看到的代码）的唯一方法是经常提交你的任务并且不要觉得麻烦。它可以解决你的问题，不过这样做也会对你的工作产生其他的影响： 1.每个提交的修订都会为你提供一个还原点。如果你完全把代码搞砸了（没骗你，我们都这么做过），你是希望恢复到一个小时前的工作还是一周前的工作？ 2.归并文件时会出现的危险会随着时间不断增加。归并文件一直很麻烦。如果你不是每天都保持提交代码，某一天你会突然发现你和其他人的更改内容会有50多个冲突。你不会为此感到高兴的。 3.它促使你把任务分离成分散的单元。通常人们都是快完成的时候才提交的，因为他们想把代码做成一个完整的逻辑单元模块。不过庞大的任务不可避免地要分离出较小的分散功能，而频繁地提交它们会使你更了解它们，你可以一个个地构建并提交。 如果你做到这些，你的提交历史不可避免地开始类似于一种半规律的样式，里面每个工作日都是在提交任务。当然不总是这样，也有停下来重构或测试，或者其他合理的活动也会中断标准的开发周期。 然而，当我在看一个独立的——尤其是完整的项目时，每当发现我们在一个标准的开发周期里，有一天或几天什么都没有做，我便会非常担忧。我之所以担忧 是因为这意味着什么地方出问题了。一般不是有人正在想方设法要把问题搞定的话，就是因为卡在某个问题上而导致项目完全没有进度。无论到底是什么情况，源代 码管理软件都会告诉你出现问题了。 第四诫：提交前要检查你更改了什么 往源代码管理软件里提交代码的步骤其实非常简单。（你恐怕会困惑上一条为什么说的那么麻烦。）一般只要发现文件内容有变更时都会不顾后果地把文件传上去。像这样——“我的项目根目录下有文件内容变更了，我要快点提交上去！” 如此会发生一件（或两件）事情：首先，程序员会没有意识地把目录下的垃圾代码文件也上传上去。一些人看到类似下面的窗口时，就会点击“选择全部”然后提交——这样源仓库里就会被本不应该存在的未调试的文件和其他垃圾文件给弄乱。
或者是，程序员实际上并没有检查他们更改过什么就把文件上传了。当你在工作中处理配置文件或项目定义文件时很容易就不经意把那些不想提交的文件给上传了，而且那些文件很可能就被别的程序员用到了。你真的会记住你在配置文件里的所有更改吗？
解决方法很简单：你必须在提交前立刻检查你改过什么地方。做起来其实比听起来还要容易。使用许多系统已经提供的“忽略”特性可以大幅度地减轻“不经意上传文件”的危险。你可以忽略Thumbs.db文件因为你压根不想上传它。你在每次修订后可能还有其他文件不想上传——那么就忽略掉它们吧！ 至于文件里的更改，你通常可以使用某个流行的文本比较工具来观察差异。为什么我又要上传一次Web.config文件呢？
噢，我想起来了，我想把尝试密码失败的最大次数从5次减少到3次。啊，我差点没注意把一个虚拟的登录页面给上传上去了。这种在提交前做检查的练习可以让你更容易理解下一节的内容。 第五诫：写提交信息时一定要认真 这是一个古老的谚语（出处不详），大意是说“写每一条提交信息时就好象等下会读到它的人是一个斧头杀人狂，而且他还知道你住在哪里”。如果我是那个杀人狂并在研究你的代码想追踪bug的话，看到的提交信息全部都是“代码更新了”，小心，我会来砍你的！ 我的解决办法就是解释清楚为什么要提交新的代码。每次你对代码进行更改都是有原因的。可能什么地方会崩溃。可能客户不喜欢现在的主题颜色。可能你仅仅要调整一下构建配置。无论是什么，这都是有原因的而且你要把原因用文字保留下来。 为什么？这样做的原因有很多，而且在不同环境下各不相同。举个例子，使用“归属”特性或其他类似的功能显示出谁改了代码那些地方。如果我不记得18 个月之前我对项目的Web.config文件改过什么地方或者我为什么要改动应用程序的设置，是因为我没有在当时留下一个适当的提交信息，而现在会非常简 单：
这是一个可以随时观察代码更改的软件的一种。无论我像下面那样想了解一个文件的完整更改历史，还是只想知道团队昨天做了什么，留下一个描述性的相关记录意味着只要不经意一瞥就能知道是什么情况了。
最后强调一下，当调试遇到错误时提交信息的重要性是无法估计的。举个例子，在你的集成环境里的最后更新的地方可以找到出错的原因。我的例子是非常显而易见的，不过把信息表示出来可以把很多棘手的问题变得极好解决。
把这条牢记于心，这里列出一些提交信息的反面教材： 1.可恶 好的，我从Stack Overflow网站的哪些是你写过的最差劲的提交信息（译者注：帖子已经被删除了，原因难道是出现了脏话？）帖子里选取了以上内容，不过它们和我以前看过的提交信息并不相同。它们没有告诉你有关代码更改的任何有效信息；它们都是垃圾信息。 关于提交信息最后要注意的是；同一个程序员之后提交信息绝不能和前面的完全相同。原因很好理解：你向源代码管理 软件提交文件是因为对于上一个版本的代码有东西改变了。你现在的代码和之前的已经不一样了，如果你的提交信息是完整准确的，理论上就不能和前面的相同。如 果是相同的（可能有时真的会这样），日志就会难以阅读，因为没有办法区分两条提交有什么区别。 |
