转自IT瘾投稿 我还没有见过比源码版本控制这样跨任意编程语言更基本的工具。 这是我们用过的最基本的工具，是很多开发团队的生命线。 那么，为什么我们经常会用错呢？ 为什么一些真正的核心，版本控制系统的基础往往知之甚少？ 我总结了10个实践 或“戒律” – 这通常是发生故障或错误理解的开始， 是与版本控制产品和编程语言无关的。 我会从Subversion和.NET挑选一些例子，但它们广泛适用于其他技术。 1. 如果还在使用VSS，马上停手 平心而论，在1995年VSS曾是一个伟大的工具。 不过因为有了像Subversion甚至分布式的如Git和Mercurial工具变得黯然失色。 很多年前微软已经明确表明废弃它了！ 由于一系列的重大缺陷，VSS曾受到广泛的几乎一致的鄙视， 俗称为微软的源代码破坏系统 。 2. 如果源代码没有处在版本控制，那等于还没有 每天重复此咒语 – “进步的唯一标准是工作代码处在源代码控制中”。 直到你的成果出现在源代码控制里 – 变成源控制库中的项目 – 否则它根本不存在。 当然，你已经把代码做好在本地计算机上的某个地方，但，对其他人来说这不是真的做好了，对吗？ 他们不能拿到你的版本，他们不能合并他们的修改，你无法部署它（除非你部署出错 ），一旦发生硬盘损坏你将永久丢失这些文件。 你要保持除非提交否则根本还没有的心态，一大堆的其他良好的运作因为没有提交开始陷入困境。 你应将任务分解成更小的单位，这样你可以原子地提交。 您应频繁地整合，保证自己不受本地硬件故障的影响。 但更重要的是（至少对你的团队领导来说），你证明你实际做了东西。 燃尽图曲线下降或分解列举任务列表是很棒的，但他们真的顺畅吗？ 除非这些与工作源码控制中的工作代码关联上，他们才意味着完成。 3. 尽早提交，频繁提交，越快越好 继续上一点，只有这样，才能避免“幽灵代码” -那些只有你可以在你本地计算机上能看到的代码-要尽快地尽早地频繁提交到VCS版本控制系统里 。 上面提到的是应尽早和经常的完成提交，但其中有几点可以使你的工作方式有意义： 1，每个提交的修订版能给你一个回退的位置。如果你完全搞砸了，你想回滚一个小时的变化还是一个星期的吗？ 2，合并噩梦的风险不会显着增加。合并从来就没有乐趣。 当你几天没提交代码时，你突然发现到你已经与其他人的变化有50个冲突，你肯定不开心。 3，它会强迫你将功能隔离在分散的工作单元。比方说，你已经有了一个3人天功能需实现。 通常，因为他们想试图整个地构成一个逻辑单元直到这段时间结束才提交。 当然，像这样大的一个任务不可避免地由小规模，分散的功能组成，频繁提交迫使你识别这些原子小任务，然后逐一地完成它们提交给VCS。 当你以这种方式工作时，你的提交历史形成一个有规律的模式，每天多次提交。 当然，并不总是保持这样不变的模式，有时我们停止开发和重构进入测试阶段，或任何其他中断正常的开发周期的活动。 然而，当我看到一个独特的 – 甚至整个项目，在一个正常的开发周期，有整天甚至很多天什么没提交，我很担心。… Continue reading 良好的源代码控制管理十戒