svn - SVN 用户指南

Question

我的任务是为我公司的开发人员编写一组 SVN 用户指南。

指南仅从用户角度（例如提交评论、何时提交）而不是从管理角度（例如何时标记、如何构建）。行政指南将写在单独的文件中。

我们是一家应用程序开发公司，也参与嵌入式开发。因此，我们的开发人员范围从 HTML5 和 Flash 到 Java 和 C。我们的一些编码涉及分叉非常大（数百万个文件）的代码库。其他部分涉及我们从事底层开发。

从用户（即 grunt 开发人员）的角度来看，是否有使用 SVN 的最佳实践？

Answer 1

这是一个相当主观的问题，所以我不会反对 TPTB 关闭它。不过，我很乐意就此发表我的看法。请记住，我来自在中小型（10-50 名开发人员）企业环境中工作的背景，因此我的意见是针对该环境量身定制的。

1. 您的开发人员应该了解 subversion。让他们阅读颠覆书籍，尤其是“基本工作周期”部分。我的许多其他建议都来自 svn 书。
2. 尽早并经常提交。开发人员应该努力在不破坏或不稳定的小块中完成工作。如果您没有每天至少检查一次您的工作，则可能有问题。
3. 更新非常频繁。您想提取团队其他成员每天多次执行的最新工作。如果另一个开发人员正在处理相同的文件，这也有助于减轻合并更改的痛苦。
4. 始终提供有用的评论。开发人员应编写签入注释，以对团队其他成员有帮助的方式描述已完成的工作。诸如“fixed build”、“more changes”或“x”之类的评论（真实的故事，我与一位评论总是“x”的开发人员一起工作）没有用。

以下是更多“管理员”指南（在您的分类中），但仍与开发人员相关。此外，这些都更加主观，因此请多加一点盐。

1. 保持稳定、可释放的躯干。如果您的开发人员遵循上述准则 (2)，您应该能够保持主干稳定和可发布。避免进行大的、跨领域的、不稳定的更改——找出一种方法以风险较小的小块进行这些更改。保持稳定的主干可以让您更频繁地部署，从而更快地为您的用户提供价值。
2. 使用每次发布的分支工作流。如果您需要修复错误，请为每个版本创建一个新分支。避免从主干发布或从主干“提升”到静态发布分支。
3. 避免功能分支。功能分支鼓励您想要避免的那种不稳定的、跨领域的更改。相反，尝试在主干中进行大规模更改，但通过配置开关等在生产软件中保持它们“停用”。您想争取一种架构，该架构允许您实现“大”功能，而无需破坏和隔离代码行。在这里使用控制反转是一个很大的帮助。

Answer 2

为了补充@Stuart Lange 的好建议，这是我已经磨练了一段时间的清单。这来自于我的经验和我对我的TortoiseSVN 和 Subversion Cookbook的研究，这些书在 Simple-Talk.com 上连续出版（第 8 部分最近出版，还有更多内容）。为简洁起见，我在这里只列出项目符号——我的系列文章非常详细地为所有这些提供了基本原理和支持。

A. 每个提交都应该有一个原因。

B. 一个单一的原因应该一起提交：代码、帮助文件、数据库模式等。

C. 提交不应该破坏构建。

D. 总是有理由提交文件。

E. 始终逐行审查您将要提交的内容。

F. 使提交消息成为必需。

G. 及时提交。

H. 尽可能在您的版本控制系统中进行文件操作（移动、复制、重命名）。

I. 在源代码控制中包含除您生成的文件之外的所有内容（包括第 3 方二进制文件）。

J. 永远不要孤立地进行提交：将 SVN 更新/手动验证/SVN 提交视为“原子”操作。