源代码管理十诫

若是还有可以毫无偏见地涉及各个编程语言，比源代码管理软件更必要的工具，我倒是很想见识一下。源代码管理软件是我们工作的必备工具，是许多开发团队的血液。那为什么我们都会对它有所误解呢什么都很难理解版本控制系统的核心价值和基本原理呢/p>

我总结出10条惯例——如果你愿意也可以用“戒律”——意味着必须服从它而且从一开始很难去理解。它们与所有类型编程语言的版本控制软件都有关联。在这里我选取了Subversion和.NET的几个例子，不过它们也广泛地适用于其他的一些技术。

第一诫.如果你现在还在使用VSS－请立刻停手

它已经死了。当然不完全对，它也存活了许多年，被全新的更实用的源代码管理工具超越之后还在苟延残喘地活着。准确地说当微软几个月后不再为其提供支持时(还是会坚持一段时间的)，它才是真的死了。

平心而论，VSS还是一个不错的工具。在1995年，它的光芒被像Subversion这样类似于Git和Mercurial的分布式软件给遮盖住了。微软表示要取代它已经好多年了。

原因是因为不支持如今的标准所导致的一系列缺陷使它一直不被看好。众所周知它是微软的悲剧系统，但不知何故它能坚持这么久，尽管它有那么多小故障，缺陷，并且不包含必需的功能（相对于今天的标准）。 

第二诫.如果代码没放在源代码管理软件里，等于它不存在

每天重复读这句话——“使用源代码管理软件是唯一的有效措施”。除非你在工作时使用项目的源代码管理库来控制代码版本——否则代码等于没有存在过。

显然你曾发觉在你的本地机器上运行良好的代码在其他人那里运行的效果并不理想。是不是们不能获取你的最新版本，他们没法去归并代码文件，你没有正确地部署它（参考you’re deploying it wrong）而且如果你的SSD硬盘坏了的话你将永远地失去你的劳动成果。

只要你保持这个心态——代码只有提交后才是真的安全，才是其他良好编程习惯的保障。你可以把你的任务划分成许多很小的单元以便你逐一提交。你需要频繁地这么做。你就不必担心你的硬件会不会出棘手问题。

不过更重要的意义是（至少对于你的团队领导来说），通过源代码管理软件可以看到你做了什么。使用图表并列出项目清单是个好方法，不过怎么知道他们实际上在做些什么使用源代码管理软件进行工作就能看得一清二楚了。

第三诫.要早提交，常提交，并且不要觉得麻烦

关于前面那点，避免“幻影代码”（就是只能在你的机器上看到的代码）的唯一方法是经常提交你的任务并且不要觉得麻烦。它可以解决你的问题，不过这样做也会对你的工作产生其他的影响：

1.每个提交的修订都会为你提供一个还原点。如果你完全把代码搞砸了（没骗你，我们都这么做过），你是希望恢复到一个小时前的工作还是一周前的工作/p>

2.归并文件时会出现的危险会随着时间不断增加。归并文件一直很麻烦。如果你不是每天都保持提交代码，某一天你会突然发现你和其他人的更改内容会有50多个冲突。你不会为此感到高兴的。

3.它促使你把任务分离成分散的单元。通常人们都是快完成的时候才提交的，因为他们想把代码做成一个完整的逻辑单元模块。不过庞大的任务不可避免地要分离出较小的分散功能，而频繁地提交它们会使你更了解它们，你可以一个个地构建并提交。

如果你做到这些，你的提交历史不可避免地开始类似于一种半规律的样式，里面每个工作日都是在提交任务。当然不总是这样，也有停下来重构或测试，或者其他合理的活动也会中断标准的开发周期。

然而，当我在看一个独立的——尤其是完整的项目时，每当发现我们在一个标准的开发周期里，有一天或几天什么都没有做，我便会非常担忧。我之所以担忧 是因为这意味着什么地方出问题了。一般不是有人正在想方设法要把问题搞定的话，就是因为卡在某个问题上而导致项目完全没有进度。无论到底是什么情况，源代 码管理软件都会告诉你出现问题了。

第四诫.提交前要检查你更改了什么

往源代码管理软件里提交代码的步骤其实非常简单。（你恐怕会困惑上一条为什么说的那么麻烦。）一般只要发现文件内容有变更时都会不顾后果地把文件传上去。像这样——“我的项目根目录下有文件内容变更了，我要快点提交上去！”

如此会发生一件（或两件）事情：首先，程序员会没有意识地把目录下的垃圾代码文件也上传上去。一些人看到类似下面的窗口时，就会点击“选择全部”然后提交——这样源仓库里就会被本不应该存在的未调试的文件和其他垃圾文件给弄乱。 

解决方法很简单：你必须在提交前立刻检查你改过什么地方。做起来其实比听起来还要容易。使用许多系统已经提供的“忽略”特性可以大幅度地减轻“不经意上传文件”的危险。你可以忽略Thumbs.db文件因为你压根不想上传它。你在每次修订后可能还有其他文件不想上传——那么就忽略掉它们吧！

至于文件里的更改，你通常可以使用某个流行的文本比较工具来观察差异。为什么我又要上传一次Web.config文件呢nbsp;

这是一个可以随时观察代码更改的软件的一种。无论我像下面那样想了解一个文件的完整更改历史，还是只想知道团队昨天做了什么，留下一个描述性的相关记录意味着只要不经意一瞥就能知道是什么情况了。 

把这条牢记于心，这里列出一些提交信息的反面教材：

1.可恶
2.能跑了
3.解决了一些混帐问题
4.解决了
5.改进了一点bug
6.上传了
7.排字错误
8.修订1024

好的，我从Stack Overflow 站的哪些是你写过的最差劲的提交信息（译者注：帖子已经被删除了，原因难道是出现了脏话帖子里选取了以上内容，不过它们和我以前看过的提交信息并不相同。它们没有告诉你有关代码更改的任何有效信息；它们都是垃圾信息。

关于提交信息最后要注意的是；同一个程序员之后提交信息绝不能和前面的完全相同。原因很好理解：你向源代码管理 软件提交文件是因为对于上一个版本的代码有东西改变了。你现在的代码和之前的已经不一样了，如果你的提交信息是完整准确的，理论上就不能和前面的相同。如 果是相同的（可能有时真的会这样），日志就会难以阅读，因为没有办法区分两条提交有什么区别。

第六诫.你必须自己提交你的更改内容——不能委托他人

听起来很奇怪，但它的确会发生，我看过不止一次，最近的是上周。情况是这样的，源代码库被视为极高的地位。因为很多原因，团队会去追求完美代码的洁 净和单一。为了保持这种神圣的状态，代码只能由某个领头的程序员来提交，他在提交前会小心地整合，审查并（大概会）调整改善代码。

即使站在很远也能很容易评价这个方案。不太频繁的提交（可能一周几次），只有一个脱离团队其他程序员的人来提交，而且不可避免地在这段漫长的无提交时期里会有人的工作会导致项目混乱。非常非常不好。

这样做会有两个错误：首先，源代码管理软件并不意味着它里面代码是神圣不可侵犯的；至少在整个开发周期里是这样的。它应该是团队频繁整合文件，在出错时还原到正常并且共同解决问题的地方。不是自始至终都要这样做，只有在应用程序周期的发布时期为了达到某种状态时才做的。

另一个问题——并且真的是极为关键的——站在程序员的视角，这样等于你压根没有在用源代码管理软件！它等于没有同伴之间的代码整合，没有还原，提交信息没有负责人，什么都没有！你们仅仅是在自己的象牙塔里各自写各自的代码然后等着未来顺便某一天把它交给领导就完事了。

不要这样做。千万不要。

第七诫.一定要管理好数据库的版本

假如你没有立刻清理的话，多余出来的就是扩展文件和类型描述，也就是.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:)

原文来自：The 10 commandments of good source control management
中文翻译：图灵 区

转自：http://www.oschina.net/news/38327/10-commandments-of-good-source-control

文章知识点与官方知识档案匹配，可进一步学习相关知识Git技能树首页概览2872 人正在系统学习中 相关资源：倒计时软件.exe_倒计时电脑软件-管理软件工具类资源-CSDN文库