SVN最佳实践 - 在团队中工作

Question

我开始使用SVN。我知道基本命令并理解基本原理。我想知道是否有人在团队环境中使用Subversion有任何提示或最佳实践。

我可以看到在提交代码时添加合理冗长的消息的好处，但还有其他我应该记住的事情吗？

感谢所有出色的答案 - 他们帮了很多忙。

Answer 1

鼓励频繁提交。对版本控制不熟悉的队友可能会觉得他们需要将代码保留在存储库中，直到“它正常工作”。教导每个人尽早提交，并经常尽快找到问题。而不是保持代码“直到它工作，建议你的队友创建可能破坏主干的功能分支。这导致......

建立分支和标记实践。除了功能分支外，还鼓励您的队友使用分支来修复大错误。在工作的开始和结束时标记主要错误修复。为生产/ qa版本维护标签（以及可能的分支）。

为trunk建立策略并坚持下去。一个例子可能是，“trunk必须始终构建没有错误。”或“主干必须始终通过所有单元测试”。任何不能满足行李箱标准的工作必须在分支机构完成。

Answer 2

不要在代码更改时提交格式更改

如果你想重组一个巨大的文件的空格（ Control + K + D ），那很好。提交格式更改与实际逻辑更改分开。如果要在文件中移动函数，也是如此。将移动与实际编辑分开。

Answer 3

我一直坚持的一个关键概念是一起提交相关的代码更改。推论是不会在同一次提交中提交不相关的代码更改。这意味着不要在一次提交中修复2个错误（除非它是相同的修复），并且不会在2次提交中提交一半错误修复。此外，如果我需要在系统的一个不相关的部分添加一些新的增强或某些东西，然后我需要进行其他工作，我会单独提交增强功能（首先）。这个想法是任何人可能想要拥有的任何改变（或自行回滚）应该是一个单独的提交。在进行合并或回滚损坏的功能时，它将为您节省大量的麻烦。

Answer 4

已经提到了很多，这里还有一些：

1. 如果您有源控制中不需要的文件（例如配置，编译文件等），请将它们添加到忽略列表。通过这种方式，您可以注意到任何您忘记添加的文件，总是期望显示为SVN未知的文件的空列表。

2. 添加一个帖子提交事件，该事件将向您的开发人员邮件列表发送电子邮件（或针对此目标的特定信息）与提交的更改相关，理想情况下是针对该修补程序的修补程序。< / p>

3. 与您的错误跟踪器集成，以便通过指向错误链接的错误/功能请求显示对提交的引用。像MantisBT这样的错误跟踪器支持此功能。

4. 考虑与持续集成（例如CruiseControl.NET），NAnt进行构建，以及NUnit / VS进行单元测试。这样，一旦用户签入代码或在计划的时间间隔内编译代码，就会运行单元测试，并且开发人员会获得该流程的反馈。如果存储库被破坏（即不构建），这也会警告团队的其他成员。

Answer 5

嗯，基础知识：

• 在版本
上启动QA之前创建标记
• 在风险变更之前创建标签（即大型重构）
• 为已发布的版本创建分支以冻结代码。
• 确保人们知道在开始处理一段代码之前更新并在提交之前再次更新。
• SVN允许不同用户对同一文件进行多次检出。确保每个人都能解决可能发生的任何冲突。
• 从不为多个用户使用相同的SVN帐户。可能会导致可怕的事情。

Answer 6

人们给出的答案很棒。其中大部分内容在best practices for SVN的svn用户文档中进行了总结 重复：

1. 设置您的存储库结构（您应该在项目根目录下包含主干，分支和标签）
2. 选择您的政策重新分支（私人分支机构， 每个里程碑/发布/错误的分支， 等等）坚持下去 - 我会 建议更多分支而不是 少，但不需要私人 分支机构
3. 选择您的政策 标记 - 更多标记越好，但是 最重要的是决定你的标签 命名惯例
4. 选择你的 政策重新承诺 - 保持行李箱尽可能“干净”， 它应该可以在任何时候发布 时间

Answer 7

我想总结一下我坚持的最佳实践：

1. 不提交二进制文件。应该有单独的二进制存储库，例如 Nexus ， Ivy 或 Artifactory 。

2. 应该有存储库结构。我个人使用以下存储库结构：

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. 使用分支类型的特定列表。我的列表如下： experimental ， maintenance ， versions ， platforms ， releases 。
4. 使用特定类型的代码：PA（pre-alpha），A（alpha），B（beta），AR （alpha-release），BR（beta-release），RC（候选发布版），ST（稳定）。
5. 尽量减少合并的必要性。在可能/鼓励合并时以及不合并时应该有规则。
6. 版本编号。应该有坚定的版本编号方法。通常它在软件配置管理计划等文档中描述，它是高级项目文档的一部分。我个人使用复杂的版本编号方法。根据这种方法，版本具有以下模式： Nxx （维护/支持分支）， NMx （发布分支）， NxK （构建）， NMK （发布）。
7. 尽可能频繁地提交。如果它很难（例如，为了实现功能甚至编译代码时应该进行太多的更改），应该使用实验分支。
8. 中继应包含最新的开发。例如，如果可以选择在哪里开发应用程序的新主要版本（ Nxx ），在 trunk 或分支中，则应始终做出有利于躯干。旧版本应分支到 maintenance / support 分支。它假设主要版本之间有明显的区别，并且它们的具体内容（架构，兼容性）尽早出现 。
9. 严格'不要破坏发布分支上的构建'政策。同时，对于 trunk ，它不一定要严格，只要它可能有实验开发或代码库需要解决合并问题。
10. 使用 svn：externals 。它将允许模块化您的项目，建立透明的发布管理程序，分割和征服不同的功能。
11. 使用问题跟踪。您将能够在提交消息中指出问题参考。
12. 禁用空提交消息。它可以使用预提交挂钩来完成。
13. 定义您希望持续集成的分支。例如，我更喜欢使用 trunk ，维护和发布分支的持续集成。
14. 为不同类型的分支机构建立持续集成策略。正如我前面指出的，最严格的“不破坏构建”规则适用于发布分支，而 trunk 和维护分支可能是有时候坏了。此外，在主干/维护和发布分支上运行的检查列表之间也存在差异。

您可以以diagram的形式找到我的颠覆最佳实践概述，说明我使用的软件配置管理方法的主要原则。

Answer 8

我发现非常有用的一件事是svn:external属性，这意味着您可以将其他存储库中的目录引用到您自己的库中。它提供了组织代码和数据的非常好的方法。一些例子是：

1. 如果您有一个单独的存储库，用于代码中您使用的不同模块/库和引用。这意味着您可以为每个可执行文件创建一个元库。如果它是一个只使用少量模块的小型可执行文件，则不需要签出整个树。这样做的结果是您获得每个模块的SVN修订号。
2. 将大型二进制数据（如编译版本的库）添加到代码存储库通常被认为是一种坏习惯，但它确实非常方便。如果您只是将您使用的所有库的所有版本添加到不同的存储库，那么您可以获得两个世界中最好的。您可以在您使用的库的版本中引用代码库。检查代码库时，您将同时获得代码和二进制文件。但是，二进制文件存储在一个大型存储库中，您不需要像源代码那样严格备份，并且源代码存储库保持较小且仅包含文本。

Answer 9

与您的错误跟踪软件集成使用。如果您使用Bugzilla，则可以对其进行设置，如果您的评论以“Bug XXXX”开头，您的SVN评论会自动添加为对给定错误的评论，包括指向该版本的SVN Web界面的链接。

Answer 10

了解SVN的分支和合并工具和约定。

与其他团队成员合作的最佳方式是将工作分解为完整的开发功能/修复，然后在分支中处理各个更改。然后在完成/准备/批准合并后将更改合并回主线分支/主干。

这样，个人可以朝着共同的目标努力（在同一个分支或单独的分支上），而不会与其他变化发生冲突。

您的里程可能会有所不同，这对于只有两个人来说可能有点过分。

Answer 11

如果您使用与SVN良好集成的好工具，它会更容易。通过这些功能，您可以轻松查看已更改的内容，然后提交全部或部分更改，并经常将工作副本更新为SVN中的最新版本。

我建议Tortoise SVN（如果您使用的是Windows）和Visual SVN（如果您使用的是VS）。

另请参阅是否可以对其进行设置，以便在提交更改时随时收到电子邮件或类似通知（通常还包括提交消息和已更改文件列表）。 CVSDude等服务提供此功能。我发现在更新我的工作副本之前知道已经进行了更新然后知道该更新中包含的内容是有帮助的。

Answer 12

源代码管理的黄金法则：提前入住，经常登记

有关如何组织存储库的提示：

• How do you organize your version control repository?
• SVN Book Chapter 5. Repository Administration
• Repository layout

Answer 13

除了分支政策等。 （其中一个尺寸绝对不适合所有），你应该有很好的提交：

• 如果可能，提交应与单个工作相关;一个错误修复，一个新功能 - 你应该对你所做的改变有一些“逻辑”
• 提交应该有一个描述性注释，可以帮助您找到它浏览存储库历史记录。大多数人建议在开头写一个句子来描述整个提交，并在下面写一个更详细的帐户
• 如果可能，您应该尽可能将提交绑定到您的错误跟踪系统。 Trac，Redmine等。让你创建从bug到提交的链接，反之亦然，这非常方便。

Answer 14

在修复任何合并冲突之前，请咨询您的团队，了解他们的更改，或者至少仔细查看差异。让他们自己检查合并的代码，以确保他们的添加不会在合并中丢失。

Answer 15

与bug跟踪器和提交策略实施集成的一个示例可能是Trac svn pre / post-commit钩子脚本，如果提交消息不引用bug中的任何票证，它可以拒绝提交-tracker并根据消息内容向现有故障单添加注释（即提交消息可能包含类似“修复＃1，＃2和＃8”的内容，其中＃1，＃2，＃8是故障单号）。

Answer 16

我看到的减少损坏提交的一件事就是拥有良好的预提交脚本。例如，您可以在提交更改之前运行任何单元测试。这会导致提交有点慢，但是你可以通过避免踩到某个人的脚趾而不得不道歉来节省时间。当然，当你拥有一个庞大的开发团队和非常频繁的提交时，这将变得更加难以管理。

Answer 17

SVN本身就是一个良好的开端，其他一些海报也就最佳实践提出了一些很好的建议。

我唯一要补充的是，您应该使用CruiseControl或TeamCity连接SVN以推动持续集成流程。这将发送构建电子邮件，让每个人都知道有人打破了构建。

很早就会告诉你谁在追踪你的过程，谁不是。可能导致一些摩擦，但从长远来看，你的团队会更好。

Answer 18

• 每次提交的精确评论

• 不要破坏（主线）构建！

• 逻辑单位更改后立即提交

• 避免使用Subversion作为备份工具

• 尽可能少分支/合并

更多详细信息，请参阅 SVN best practices 。

Answer 19

使用SVN的最佳做法：

1. 当您第一次上任并打开Eclipse项目时，必须要做的第一步是更新您的项目。

2. 更新后，开始工作。完成编码后，请正确检查，您的应用程序是否正常运行，没有任何异常。一旦你确定你的代码工作正常，就可以提交代码了。

注意：提交代码时，请勿直接提交。与服务器建立同步并检查所有需要提交的内容。 注意：不要提交整个文件夹一次。因为您可能已根据需要对文件进行了一些更改，或者您可能已删除了本地系统中的某些文件。但是服务器上的设置不同。因此，请单独检查文件并提交代码。

1. 不要直接提交/更新冲突文件。

2. 何时进行覆盖和更新？

   当你非常确定你不需要任何本地人时 更改并希望完全更新服务器副本。记下来 一旦你进行覆盖和更新，你就不会得到任何你的 当地的变化。

   注意：请勿在未更新的情况下保留项目超过一天。也不要在没有提交许多天的情况下保留代码。

3. 沟通谁在同一个组件中工作，并讨论他们每天所做的改变。

4. 除非有某些原因，否则不要提交属性和配置文件。因为服务器和云端的设置会有所不同。

5. 不要将目标文件夹提交到SVN，只需要在SVN存储库中维护源代码和资源文件夹。

6. 当您丢失代码时，请不要惊慌！您可以从SVN历史记录中获取早期副本。

7. 不要将项目签出到磁盘的多个位置。在一个位置查看并使用它。

---

Answer 20

将其用于评论模板：

[task / story xxx] [minor / major] [comment] [follow up comment] [bug to bug]

Answer 21

DEV是否适用于分支

1. 经常提交到您的分支机构
2. 离散/模块提交到您的分支（see here）
3. 经常更新/合并来自主干。不要重新
，不要坐在你的分支上

社区中心

1. 应始终建立/工作
2. 每次提交一个问题（again see here）主要是因为您或其他人可以一次退出一个
3. 不要将重构/空白更改与逻辑更改混淆。你的队友将很难从提交
中提取你实际做了什么

请记住，您提交的增量，模块化，离散和简洁越多，您（或可能是其他人）就越容易：

• 逐步退出更改
• 在没有筛选大量空白区域和变量名称变化的情况下，实际看到你实际做了什么。
• 当完成的工作与消息长度的比率较低时，提交消息意味着更多。