SVN用户指南

Question

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

指南完全取决于用户的观点（例如提交评论，何时提交），而不是从管理角度（例如何时标记，如何构建）。行政指南将写在单独的文件中。

我们是一个也参与嵌入式开发的应用程序开发公司。所以我们的开发人员从HTML5和Flash到Java和C.我们的一些编码涉及分支非常大（数百万个文件）的代码库。其他部分涉及我们进行基础研发。

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

Answer 1

这是一个相当主观的问题，所以我不反对TPTB关闭它。但是，我很高兴地分享我对此的看法。请记住，我来自一个在小型/中型（10-50个开发人员）企业环境中工作的背景，因此我的观点是针对该环境量身定制的。

1. 您的开发者应该了解颠覆。让他们阅读subversion book，特别是"basic work cycle"位。我的许多其他建议都来自svn书。
2. 尽早提交。开发人员应该努力在不破坏或破坏稳定的小块中进行工作。如果你不是每天至少检查一次你的工作，可能会出现问题。
3. 经常更新。您希望将团队其他成员每天多次进行的最新工作拉出来。这也有助于减轻在另一个开发人员处理相同文件时合并更改的痛苦。
4. 始终提供有用的评论。开发人员应编写签到注释，以便以对团队其他成员有帮助的方式描述所完成的工作。像“固定版本”，“更多更改”或“x”这样的评论（真实的故事，我与评论总是“x”的开发人员合作）都没用。

以下是更多“管理员”指南（在您的分类中），但仍与开发人员相关。而且，这些更主观，所以需要更多的盐。

1. 保持稳定，可释放的行李箱。如果您的开发人员遵循上述准则（2），您应该能够保持您的主干稳定和可释放。避免做出大的，交叉的，不稳定的变化 - 找出一种方法，使那些风险较小的小块变化。通过维护稳定的中继，您可以更频繁地部署，从而更快地为用户创造价值。
2. 使用branch-per-release工作流程。如果需要修复错误，请为每个版本创建一个新分支。避免从行李箱释放或从行李箱“升级”到静态释放分支。
3. 避免功能分支。特征分支鼓励您想要避免的那种破坏稳定，交叉的变化。相反，尝试在主干中进行大规模更改，但通过配置开关等在生产软件中将它们“停用”。您希望寻求一种架构，允许您实现“大”功能，而无需破坏和隔离代码行。使用Inversion of Control是一个很大的帮助。

Answer 2

为了补充@Stuart Lange的好建议，这是我一直在磨练一段时间的清单。这来自我的经验和我对 TortoiseSVN和Subversion Cookbook 的研究，这些研究是在Simple-Talk.com上连续发布的（part 8最近发布了更多内容）。为简洁起见，我只列出了这里的项目 - 我的系列文章为所有这些项目提供了非常详细的理由和支持。

一个。每次提交都应该是出于一个原因。

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

℃。提交永远不应该破坏构建。

d。始终有理由提交文件。

电子。始终逐行检查您要提交的内容。

F。提交所需的提交消息。

-G。及时提交。

小时。尽可能在版本控制系统中进行文件操作（移动，复制，重命名）。

予。除了您的生成的文件之外，请将所有内容都包含在源代码管理中（因此执行包含第三方二进制文件）。

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