【发布时间】：2009-01-06 18:19:01
【问题描述】：
我从 SVN 开始。我知道基本命令并了解基本原理。我想知道是否有人对在团队环境中使用 Subversion 有任何提示或最佳实践。
我可以看到在提交代码时添加相当详细的消息的好处，但我还应该记住其他一些事情吗？
感谢所有出色的答案 - 他们帮了很多忙。
【问题讨论】：
标签： svn
【发布时间】：2009-01-06 18:19:01
【问题描述】：
鼓励频繁提交。 刚接触版本控制的队友可能会觉得他们需要将代码保留在存储库之外，直到“它可以正常工作”为止。教导每个人尽早承诺并经常尽快发现问题。建议您的队友为可能破坏主干的功能创建分支，而不是保留代码直到它工作。这导致...
建立分支和标记实践。 除了功能分支之外，鼓励您的队友使用分支修复大错误。在工作开始和结束时标记主要错误修复。维护生产/质量保证版本的标签（可能还有分支）。
为trunk 制定政策并坚持下去。 一个例子可能是“trunk 必须始终无错误地构建”。或“主干必须始终通过所有单元测试”。任何还不能达到trunk标准的工作都必须在分支中完成。
【讨论】：
-
分支和合并在 SVN 中是一件很痛苦的事情。其他 VCS 处理得更好，但我绝不会提倡 SVN 采用分支繁重的流程。
-
@Branan 错了。这是因为您不知道如何正确使用源代码管理。当您进行分支时，您应该作为一个优秀的开发人员来完成您的工作并从主干更新您的分支并将最新的更改从主干合并到您的分支每天或每天几次（您的选择），这样最终您就不会有已经堆积起来的合并地狱。我的 PC 上至少有 4-5 个分支一直在本地运行，这从来不是人们所说的噩梦，因为我做得对......经常更新它，以便我有人们正在检查的更改树干和工作和添加与相关的代码
不要通过代码更改提交格式更改
如果你想重组一个大文件的空白（Control+K+D），没问题。将格式更改与实际的逻辑更改分开提交。如果您想在文件中移动函数，也是如此。将移动与实际编辑分开提交。
【讨论】：
-
所以我一整天都在编辑一个文件，现在是时候提交它了，我该如何分离格式？
-
如果您要使用现有代码进行格式更改，请先执行此操作，提交，然后添加新代码/编辑代码。或者先添加/编辑，提交，然后进行格式更改。这样，添加/编辑的差异实际上是有意义的，而不是简单地说“现在一切都不同了！”。
-
+1。无关的更改会增加审查相关更改的工作量。也使得合并/移植更改变得更加困难（也就是说，不同的分支）。
-
虽然这是一个很好的做法，但我认为没有人能够强制执行。 Jason 是对的，优秀的开发人员会意识到他们可以使用优秀的 diff 工具（内置于 tortoise SVN 中）忽略空格来过滤掉噪音。
-
这可以通过代码审查和对团队成员的教育来实施。我认为将逻辑更改与代码更改分开不应该成为审阅者的负担。这应该是实施者的责任。
我一直坚持的一个关键概念是一起提交相关的代码更改。推论是不要在同一个提交中提交不相关的代码更改。这意味着不要在一次提交中修复 2 个错误（除非它是相同的修复），并且不要在 2 次提交中的每个提交中提交一半的错误修复。此外，如果我需要向系统的不相关部分添加一些新的增强功能或某些东西，然后我需要进行其他工作，我会单独（并且首先）提交增强功能。这个想法是，任何人可能想自己拥有（或自己回滚）的任何更改都应该是一个单独的提交。当需要进行合并或回滚损坏的功能时，它将为您省去很多麻烦。
【讨论】：
-
对此+1。当你承诺时，这似乎是一种痛苦。但是，当您查看旧代码时，一个充满原子提交的 repo 是无价的。
-
这不是功能分支的用途...根据需要在功能分支上进行尽可能多的提交，然后当您准备好将其合并到主干...回滚仅意味着删除合并提交。 +1 用于将相关代码放在一起...
已经提到了很多，这里还有一些：
如果您有不需要在源代码管理中的文件（例如配置、编译文件等），请将它们添加到 忽略列表。通过这种方式，您会注意到任何忘记添加的文件，因为您总是期望一个空的文件列表显示为 SVN 未知。
添加一个提交后事件，该事件将向您的开发者邮件列表发送一封电子邮件（或一个特定于该目标的邮件），该事件与已提交的更改以及理想情况下的补丁相关。
与您的错误跟踪器集成，以便对提交的引用显示在错误/功能请求中，并带有指向差异的链接。像 MantisBT 这样的错误跟踪器支持这一点。
考虑与持续集成集成（例如CruiseControl.NET），NAnt 用于构建，NUnit/VS 用于单元测试。这样，一旦用户签入代码或在预定的时间间隔内代码被编译，单元测试就会运行，并且开发人员会获得该过程的反馈。如果存储库损坏（即未构建），这也会提醒团队的其他成员。
【讨论】：
-
我们使用的做法是所有配置文件都更改了扩展名，如 config.php.config 或类似的东西，这样我们将配置文件保存在服务器上，但每个团队成员都有自己的。当配置文件发生重大变化时，我们复制表单 svn 版本...
好吧，基础知识：
- 在开始对版本进行质量检查之前创建标签
- 在有风险的更改（即大重构）之前创建标签
- 为已发布的版本创建分支以冻结代码。
- 确保人们在开始处理一段代码之前知道要更新，并在提交之前再次更新。
- SVN 允许不同用户多次签出同一个文件。确保每个人都解决可能发生的任何冲突。
- 切勿为多个用户使用同一个 SVN 帐户。可能会导致可怕的事情。
【讨论】：
-
我的分支和标签正好相反。分支用于来自主干的分叉，最终与主干合并。标签用于代码冻结。
-
分支是可以更改的副本。标签是不应更改的副本。 svnbook.red-bean.com/en/1.2/svn.branchmerge.tags.html
-
我做类似的事情。当我将代码发布到 QA 或生产环境时，我会进行标记和分支。这样，我们就有了一个只读标记和一个分支来解决该版本的错误修复，这些错误修复不会影响可能在主干上进行的新功能开发。
-
Svn 还允许同一个用户多次检出同一个文件夹。因此，如果您发现需要进行与当前工作无关的更改（例如，某些客户要求紧急修复或您偶然发现完全不相关的错误）再次结帐并单独修复。
-
"tags" 应该用于代码冻结。如果您尝试更改“标记”分支，您的 SVN 客户端甚至会警告您。
人们给出的答案很棒。大部分内容在 best practices for SVN 的 svn 用户文档中进行了总结。
重复：
- 设置你的仓库结构（你应该有项目根目录，下面有主干、分支和标签）
- 选择您的政策重新分支（私人分支机构， 每个里程碑/发布/错误的分支， 等）并坚持下去——我会 推荐更多分支而不是 少，但不需要私人 分店
- 选择您的保单 标记——标记越多越好，但是 最重要的是决定你的标签 命名约定
- 选择您的 重新承诺主干的政策—— 保持行李箱尽可能“干净”， 它应该可以随时发布 时间
【讨论】：
-
这是一个相当古老的最佳实践，所以我认为 CollabNet 不再推荐它们。是否有任何新的最佳实践可用？你提到的那个可以追溯到 SVN 1.0
-
@mliebelt - 我更新了 apache 版本的链接。无论年龄大小，选择你的 repo 结构、分支策略、标记策略和主干提交策略的想法，以及上面非常好的答案，仍然是合理的。
-
“需要时分支系统”的描述非常疯狂。听起来像是办公室拍摄的秘诀。
我想总结一下我坚持的最佳做法：
- 不要提交二进制文件。二进制文件应该有单独的存储库，例如 Nexus、Ivy 或 Artifactory。
-
应该有存储库结构。我个人使用以下存储库结构：
/trunk /tags /builds /PA /A /B /releases /AR /BR /RC /ST /branches /experimental /maintenance /versions /platforms /releases - 使用分支类型的具体列表。我的列表如下：experimental、maintenance、versions、platforms、releases。
- 使用特定的标签类型：
PA（pre-alpha）、A（alpha）、B（beta）、AR（alpha-release）、@987654327 @（测试版）、RC（候选版本）、ST（稳定版）。 - 尽量减少合并的必要性。什么时候可以/鼓励合并，什么时候不可以合并，应该有规则。
- 版本编号。应该有固定的版本编号方法。通常在诸如软件配置管理计划之类的文档中进行描述，它是高级项目文档的一部分。我个人使用复杂的版本编号方法。根据这种方法，版本具有以下模式：N.x.x（维护/支持分支）、N.M.x（发布分支）、N.x.K（构建）、 N.M.K（发布）。
- 尽可能频繁地提交。如果比较困难（例如，为了实现功能甚至编译代码需要进行太多更改），则应使用实验分支。
- 主干应包含最新进展。例如，当有一个选择的选择新的主要版本（ n.x.x ），在 trunk em>或分支机构中，应始终始终支持主干。旧版本应该分支到 maintenance/support 分支。它假定主要版本之间存在明显区别，并且它们的细节（架构、兼容性）会尽早出现。
- 发布分支上严格的“不要破坏构建”政策。同时，对于 trunk 不一定要严格，只要它可能具有需要解决合并问题的实验性开发或代码库。
- 使用 svn:externals。它将允许模块化您的项目，建立透明的发布管理程序，分而治之不同的功能。
- 使用问题跟踪。您将能够在提交消息中指出问题参考。
- 禁用空提交消息。可以使用预提交挂钩来完成。
- 定义您希望持续集成哪些分支。例如，我更喜欢对 trunk、maintenance 和 release 分支使用持续集成。
- 为不同类型的分支机构制定持续整合政策。正如我之前指出的，最严格的“不要破坏构建”规则适用于 release 分支，而 trunk 和 maintenance 分支可能是有时坏。在 trunk/maintenance 和 release 分支上运行的检查列表之间也存在差异。
您可以通过diagram 的形式找到我的颠覆最佳实践大纲，说明我使用的软件配置管理方法的主要原则。
【讨论】：
-
那么，你在团队中工作吗？不同的人使用不同的分支吗？如何避免冲突？你的回答不包括团队合作:(
-
问：如何避免冲突？ 答：尽量减少合并，Trunk应该包含最新的发展， 尽可能频繁地提交 问：不同的人使用不同的分支吗？ 答：每个分支都可以由一个或多个人使用。区分不同的分支类型也很重要：实验、维护和发布，这有助于避免冲突 Q：您的回答不包括团队合作 A：可能从乍一看。自动使用版本控制意味着团队合作。我描述了一组有助于更有效协作的规则（作为道路规则）
-
我是 SVN 新手，我知道这是一个老问题，但我在 2021 年仍然有一个问题。当您拥有可能也有发布的 Trunk 和标签时，为什么还要发布分支？是否真的有必要拥有一个发布分支（或多个？）。提前致谢。
-
@JuanIgnacioAvendañoHuergo：发布分支的存在是为了隔离正在进行的开发，例如，主干（很可能包含功能提交）与通过错误修复稳定发布而不接受诸如功能这样的重大更改的努力提交
我发现非常有用的一件事是svn:external 属性，这意味着您可以将其他存储库中的目录引用到您自己的存储库中。它提供了非常好的组织代码和数据的方法。一些例子是：
- 如果您有一个单独的存储库用于编码不同的模块/库，并在您正在使用的模块/库中引用。这意味着您可以为每个可执行文件拥有一个元存储库。如果它是一个仅使用几个模块的小型可执行文件，则无需检出整个树。这样做的效果是您可以获得每个模块的 SVN 修订号。
- 将大型二进制数据（例如库的编译版本）添加到代码存储库通常被认为是一个坏习惯，但它确实很方便。如果您只是将您使用的所有库的所有版本添加到不同的存储库，您可以获得两全其美。您将使用的库版本引用到代码存储库中。检查代码存储库时，您还将获得代码和二进制文件。但是，这些二进制文件存储在一个大型存储库中，您不需要像源代码那样严格备份，而且源代码存储库很小并且只包含文本。
【讨论】：
-
我喜欢第 2 点。由于您可以在使用 svn:external 时指定或不指定修订号，这将让您将某些库“固定”到特定版本，同时允许其他库“跟踪”最新版本.
-
使用 "svn:external"s 是最强大的功能之一，我想说的是 SVN 的最基本功能。这是必须的。
使用与您的错误跟踪软件的集成。如果您使用Bugzilla，您可以进行设置，如果您的评论以“Bug XXXX”开头，您的 SVN 评论会自动添加为给定错误的评论，包括指向该修订版的 SVN Web 界面的链接。
【讨论】：
-
Trac 具有良好的 svn 集成，可用于错误跟踪，以及时间线、提交差异、wiki 等。
-
Jira 还跟踪与问题相关的提交
了解 SVN 的分支和合并工具和约定。
与其他团队成员合作的最佳方式是将工作分解为完整的开发功能/修复，然后在一个分支中进行单独的更改。然后在完成/准备好/批准合并时将更改合并回主线分支/主干。
这样，个人可以朝着一个共同的目标（在同一个分支或不同的分支）工作，而不会与其他更改发生冲突。
您的里程可能会有所不同，这对于两个左右的人来说可能有点过头了。
【讨论】：
如果您使用与 SVN 良好集成的好工具，它会变得更加容易。这些使您可以轻松查看已更改的内容，然后提交全部或部分更改，并经常将您的工作副本更新到 SVN 中的最新版本。
我推荐Tortoise SVN（如果您使用Windows）和Visual SVN（如果您使用VS）。
还可以查看您是否可以设置它，以便在提交更改时收到电子邮件或类似通知（通常还包括提交消息和更改文件的列表）。像CVSDude 这样的服务提供了这个。我发现在更新我的工作副本之前了解已经进行了更新以及了解该更新中包含的内容是很有帮助的。
【讨论】：
除了分支策略等。 （一种尺寸绝对不能满足所有人的需求），你应该有好的提交：
- 如果可能的话，提交应该与单个的工作相关；一个错误修复，一个新功能 - 你提交的更改应该有一些“逻辑”
- 提交应该有一个描述性的注释，这将帮助您在浏览存储库历史时找到它。大多数人建议在开头写一个句子来描述整个提交，然后在下面写一个更详细的说明
- 如果可能，您应该尽可能将提交绑定到您的错误跟踪系统。 Trac，Redmine 等人。让您创建从错误到提交的链接，反之亦然，非常方便。
【讨论】：
源代码控制的黄金法则：尽早签入，经常签入
有关如何组织存储库的提示：
【讨论】：
在修复任何合并冲突之前，请与您的团队协商他们的更改，或者至少非常仔细地查看差异。请他们自己检查合并后的代码，以确保他们的添加不会在合并中丢失。
【讨论】：
我已经看到减少提交中断的一件事是拥有良好的预提交脚本。例如，您可以在提交更改之前运行任何单元测试。这会导致提交速度有点慢，但您可以通过避免踩到别人的脚趾而不得不道歉来节省时间。当然，当您拥有庞大的开发团队和非常频繁的提交时，这将变得更加难以管理。
【讨论】：
-
+1 用于预提交脚本。好想法。我想知道如果你尝试在不运行它的情况下提交，是否有办法让 git 给你一个打击？
与 bug-tracker 集成和执行提交策略的示例之一可能是 Trac 的 svn pre/post-commit 钩子脚本，如果提交消息没有引用 bug-tracker 中的任何票证，它可以拒绝提交并根据消息内容将 cmets 添加到现有票证中（即提交消息可能包含类似“Fixes #1、#2 和 #8”之类的内容，其中 #1、#2、#8 是票证编号）。
【讨论】：
使用SVN的最佳实践：
当您第一次来到办公室并打开您的Eclipse 项目时，首先要做的是更新您的项目。
更新后，开始你的工作。完成编码后，请检查它是否正确，您的应用程序是否正常运行，没有任何异常。一旦你确定你的代码工作正常，就可以提交代码了。
注意：在提交代码时，不要直接提交。与服务器同步并检查所有需要提交的内容。 注意：不要一次提交整个文件夹。因为您可能已经根据您的要求对文件进行了一些更改，或者您可能已经删除了本地系统中的一些文件。但是服务器上的设置不同。所以单独检查文件并提交代码。
不要直接提交/更新冲突文件。
-
何时进行覆盖和更新？
当您非常确定自己不需要任何本地 更改并希望完全更新服务器副本。记下 一旦你做了覆盖和更新，你将不会得到任何你的 本地更改。
注意：不要让项目超过一天不更新。也不要在没有提交的情况下保留代码很多天。
与所有在同一个组件中工作的人交流，并讨论他们每天所做的更改。
除非有某种原因，否则不要提交属性和配置文件。因为服务器和云端的设置会有所不同。
不要将目标文件夹提交到 SVN，只有源代码和资源文件夹必须保留在 SVN 存储库中。
当您丢失代码时，不要惊慌！您可以从 SVN 历史记录中取回较早的副本。
不要将项目签出到磁盘的多个位置。在一个位置检查并使用它。
【讨论】：
SVN 本身就是一个良好的开端，其他一些海报就最佳实践提供了一些很好的建议。
我唯一要补充的是，您应该将 SVN 与 CruiseControl 或 TeamCity 连接起来，以推动持续集成流程。这将发送构建电子邮件，并在有人破坏构建时让所有人知道。
这会很早就说明谁在遵循您的流程，谁没有。可能会导致一些摩擦，但从长远来看，您的团队会更好。
【讨论】：
-
同意，CruiseControl 多次拯救了我的团队。
【讨论】：
DEV 是否在分支上工作
- 频繁提交到您的分支
- 离散/模块化提交到您的分支(see here)
- 经常从主干更新/合并。不要在没有重新定位的情况下坐在您的分支上
社区主干
- 应该始终构建/工作
- 每次提交一个问题 (again see here) 主要是为了让您或其他人可以一次撤消一个问题
- 不要将重构/空白更改与逻辑更改混为一谈。您的队友将很难从提交中提取您实际所做的
请记住，您的提交越增量、模块化、离散和简洁，您（或可能其他人）就越容易：
- 逐步退出更改
- 无需筛选大量空白和变量名称更改，直观地了解您的实际操作。
- 当完成的工作与消息长度的比率较低时，提交消息的意义更大。
【讨论】：
将此用于 cmets 模板：
[任务/故事 xxx][次要/主要][comment][follow up comment][URL to bug]
【讨论】：