问待单元测试代码的版本控制

EN

你在登记到“主”分支之前2-3周的过程并不是不正常的，就像类似的重新设计“根管”的努力一样(有时是必要的严肃的重组工作)。

然而，我倾向于在版本控制之外的那么多时间里感到相当紧张。

1. 不要生气。
2. 不要喝醉。
3. 在没有版本控制的情况下不要长时间编写代码。

强烈建议本地开发人员在2-3周内使用Mercurial或Git进行本地版本控制，然后您可以将“最终”项目签回(主) CVS分支。它们实际上就是为这种情况而构建的。

这就是我们所做的--它是有效的，它使得各个开发人员之间的差异和补丁和协作变得微不足道。

(对我们来说，Mercurial是本地的，Subversion是“主”版本控制系统。)

...for 2-3周代码只在工程师的计算机上运行，不受版本控制...

嗯，对我来说，在版本控制之外编程就像是用倒档驱动:在技术上是可行的，但通常会适得其反。

从这个意义上说，我会说，任何其他的方法，以某种方式，允许您的开发人员不断保持他们的工作在VC下，将比什么都没有更优雅。为此，有许多已知的方法-谷歌版本控制分支策略显示了大量的资源，解释了你的选择和标准如何选择。

如果不进行试验，就很难判断这些选项中的哪一个更适合您的项目。在研究上面提到的资源时，我建议查看通常称为Feature Branch的详细信息。这个策略非常符合您所描述的“需要2-3周才能完成的模块”--尽管我不敢打赌它是否最适合您的团队。

还要注意的是，至少对于“内部”开发人员的需求，您可以选择使用旧的和不方便的CVS以外的版本控制系统。

如果您的公司策略要求在签入之前对所有代码进行单元测试，我认为这是一个很好的策略，您应该这样做:编写您的单元测试，甚至在编写代码之前。

但是如果我误解了你的意思，只是当所有的事情都做完了，应该有一个大的测试会议，那么，那就太糟糕了。你肯定会遇到麻烦的集成问题。如果您不能更改该策略，至少要有本地VCS。此外，您可以使用"featureX_Enabled“开关进行配置，并在签入时尽量不要忘记将其设置为”0“。

无论如何，改用Git或Mercurial，使用起来会轻松得多。