在最近的“意外”工作之后，我重新引入了之前修复过的一些错误，我被要求记录一套使用源代码控制的指南（本例中为CVS）。
您认为使用源代码控制的最佳做法是什么？特别是，您如何管理分支和标签，以及如何确保在继续开发新功能的同时修补当前的生产版本？对于上下文，团队规模在两个位置最多有10个开发人员。
答案 0 :(得分：8)
8 Commandments of Source Control几乎可以总结一下。
关于分支和标记我们在工作中所做的事情是：
<强>贴标
如果环境释放完成，则至少标记发布日期。然后设置所有（相关的）错误，以便“解决释放”是此标签。
<强>分支
仅根据需要创建。分支是通过标签完成的，以便可以对以前发布的版本进行更改（即修复生产中的错误而不包括所有其他错误修复）
答案 1 :(得分：2)
Eric Sink已经在他的Source Control Howto中放了一个。
答案 2 :(得分：2)
我不确定我会在同一句话中加入“CVS”和“最佳实践”。还有许多其他更好，更现代的源代码控制选择，得到社区的充分支持。
答案 3 :(得分：1)
主线模型。豆腐规模。
阅读本文：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
答案 4 :(得分：0)
尽可能经常更新（取决于项目的增长速度）这样一来，修复文件将无法重新引入。 指示开发人员在提交之前执行更新。
答案 5 :(得分：0)
答案 6 :(得分：0)
“Pragmatic Version Control（使用Subversion）”一书是一个非常好的起点。虽然它的例子是Subversion特有的，但它是所有重要概念和实践的一个很好的介绍。
答案 7 :(得分：0)
我们非常非常努力地不分支。如果我们确实创建了一个分支，那么这是一个团队决策，并经过仔细审查。所以我想这种做法是“不要轻易分支”。