在最近的“意外”工作之后,我重新引入了之前修复过的一些错误,我被要求记录一套使用源代码控制的指南(本例中为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)
我们非常非常努力地不分支。如果我们确实创建了一个分支,那么这是一个团队决策,并经过仔细审查。所以我想这种做法是“不要轻易分支”。