SVN用户指南

Question

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

这些指南将仅从用户的角度(例如，提交评论，何时提交)，而不是从管理的角度(例如，何时标记，如何构建)。行政指南将写在一个单独的文件中。

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

从用户(例如grunt开发人员)的角度来看，是否有使用SVN的最佳实践？

Answer 1

这是一个相当主观的问题，所以我不反对TPTB关闭它。然而，我很乐意分享我对此的看法。请记住，我有在中小型(10-50名开发人员)企业环境中工作的背景，所以我的观点是针对那个环境量身定做的。

1. Your开发人员应该了解subversion。让他们读取subversion book，特别是"basic work cycle"位。我的许多其他建议都来自svn book.
2. Commit早期，通常也来自。开发人员应该努力在不破坏或不稳定的情况下进行小块工作。如果你不是每天至少签入一次你的工作，那可能是wrong.
3. Update extremely 。您想要提取团队其他成员一天中多次完成的最新工作。这也有助于缓解在其他开发人员正在使用相同的files.
4. Always时合并更改的痛苦，并提供有用的注释。开发人员应该编写签入注释，以对团队其他成员有帮助的方式描述所完成的工作。像"fixed build“、"more changes”或"x“这样的评论是没有用的(真的，我和一个开发者共事，他的评论总是"x")。

以下是更多的“管理”指南(在您的分类中)，但仍然与开发人员相关。此外，这些更具主观性，因此要持更大的态度。

1. Maintain一个稳定的、可释放的主干。如果你的开发人员遵循上面的原则(2)，你应该能够保持你的主干稳定和可发布。避免做出大的、交叉的、不稳定的改变--找出一种方法，让这些改变分成小块进行，风险更小。通过维护稳定的干线，您可以更频繁地进行部署，从而为您的用户提供 workflow的价值。在需要修复bug的情况下，为每个版本创建一个新分支。避免从主干发布或从主干“升级”到静态发布branch.
2. Avoid特性分支。功能分支鼓励你想要避免的那种不稳定的、横切的变化。相反，尝试在主干中进行大规模更改，但通过配置开关等在生产软件中保持“停用”状态。您希望争取一种体系结构，该体系结构允许您实现“大”特性，而无需破坏和隔离代码行。在这里使用控制反转是一个很大的帮助。

Answer 2

为了补充@Stuart Lange的伟大建议，这里是我已经磨练了一段时间的清单。这来自我的经验和我对我的TortoiseSVN和Subversion Cookbook的研究，这两本书在Simple-Talk.com上连续发布(part 8最近发表了，还会有更多)。为简洁起见，我在这里仅列出项目符号项目--我的系列文章非常详细地为所有这些项目提供了基本原理和支持。

答:每次提交都应该只有一个原因。

C.提交永远不会破坏构建。

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

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

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

及时提交。

在源代码控制中包含除生成的文件之外的所有内容(所以一定要包含第三方二进制文件)。

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