Svn 颠覆的标准做法 我想知道是否有其他因素需要考虑使用颠覆的标准实践。< /P>

我所拥有的为数不多的是：

• /tags/trunk和/branchs的目录结构

• 所有工作都在主干中完成，不会中断功能

• 在进行重大结构更改或添加破坏核心功能的功能时进行分支（取决于首选项）

• 标签包含稳定的版本

• 在开始工作之前，始终执行更新

• 在一天结束时/添加功能时提交更改

• 提交注释包含相关的描述

• 基于功能提交-不要覆盖提交

我对在一天结束时以及添加了一项功能时提交的规则感到矛盾。我在一天结束时说，要确保存储库尽可能是最新的。但是，一天结束时的代码可能不完整/中断功能。但是，仅在功能完成时提交可能会导致过期/冲突

如果您对我的任何想法和我遗漏的任何想法提出批评，我将不胜感激

---

谢谢

在提交之前，您应该始终执行更新，以防止与其他人的其他提交发生冲突和痛苦的合并

---

此外，每次提交都应该包含一些有意义的内容，如错误修复、新功能或对现有功能的一些改进，这些内容可以在日志消息中描述。源代码管理工具不是备份工具，因此应避免在没有有意义的内容的情况下进行“一天结束”提交。

如果您是SVN新手，那么一个好的（免费）资源就是（死树副本也可以从O'Reilly处购买）。

但是，仅在功能完成后提交可能会导致过期/冲突

如果变化如此之大，以至于您担心这一点，那么您可能应该进行分支。这将允许您在不破坏构建的情况下进行增量工作时进行较小的提交，并在合并到主干后留下清晰的历史记录。

如果一个“功能”需要超过几（4-6）小时才能完成，我会

• 将“功能”划分为子任务，这些子任务可以在几个小时内完成并检查到源代码管理中
• 创建分支
• 以上两项

---

源代码控制工作流有很多变化。我们使用的是你在文章中描述的内容的扩展。您的工作流程足以进行小的修改，但如果您有多个团队处理相当复杂的不同问题，就不行了

我们所做的是为每个团队进行分支，团队可以向团队（项目）分支做出承诺。每个团队还负责将团队分支与主干进行同步，方法是将主干合并到分支，最好是在每次提交到主干之后。项目完成后，分支将合并回主干（重新集成）并删除

---

这种方法branch-merge…merge-merge-back-delete对我们很有效

我会尽可能多地提交。为了实现这一点，您必须确保您编写的代码尚未使用，或者确保所有测试都通过。如果您停留在这两种模式中的一种（后者比前者好得多），那么您就不必担心无法提交的时间过长

---

在这方面非常有帮助。

分支对于进行重大的、可能是突破性的更改是一个好主意。如果主干同时被更新，偶尔将主干合并到分支以保持分支更新

提交相关更改的原子集。不要对所有不相关的更改进行大的提交。这使得跟踪特定更改变得更加容易

您可以对同一个源进行多个签出，这在尝试不相关的更改时非常有用

避免提交损坏的代码、测试失败的代码或其他未决问题。

更多注意事项：（尽量不要重复已经说过的内容）

分支机构：

除了为上面提到的大块功能开发进行分支外，当需要进行发布后修复时，您还可以进行分支，同时主线/主干上的并行工作正在进行中

如果您使用的分支存在很长时间而没有合并到主线开发中，则定期进行反向合并。这将有助于与主干开发保持同步，并将大爆炸合并的复杂性降至最低

注意你给分支机构命名的方式。我们尝试根据里程碑命名分支。当您需要快速差异或报告时，或者在浏览某些内容时（如果名称是不言自明的），它会有所帮助

因为在SVN中，分支是一个便宜的副本，所以我们尝试总是在项目目录的根上分支（如果它是文件夹主干本身，那么分支将脱离主干）——这避免了以后关于谁在哪里分支的混淆，并避免了必须运行命令来查找它。如果你需要从一个分支签出东西，分支下的每一个标志都是可用的——如果你碰巧需要的话

承诺：

我经常在逻辑块中投票支持提交，这样您就可以通过一条公共提交消息来绑定相关文件。当你想要一个日志，并且报告是成堆地完成的，所有的文件都与相关的注释整齐地捆绑在一起时，这是非常好的

我投票支持频繁提交，如果不是每天。这是一种心态。一旦您看到了早期提交的好处（当然是在开发人员检查了基本编译错误并在他们的开发框中运行了单元测试之后），您就会很高兴发现这些早期bug/构建问题。如果您计划每晚运行构建或使用持续集成工具，那么您最好马上开始