SVN最佳实践 – 在团队中工作
我开始与SVN。 我了解基本的命令，了解基本原理。 我想知道是否有人在团队环境中使用Subversion的技巧或最佳做法。
我可以看到在提交代码时添加合理冗长的消息的好处，但还有其他的事情我应该记住吗？
感谢所有伟大的答案 – 他们已经帮了很多。
鼓励频繁提交。 新版本控制的队友可能觉得他们需要将代码保存在存储库中，直到“工作正常”。 教大家早点提前，经常尽快find问题。 而不是保持代码“，直到它的工作，build议你的队友创build分支function，可能会打破主干。 那导致…
build立分支和标记实践。 除了function分支以外，鼓励你的队友使用分支进行大量的错误修复。 标记工作开始和结束时的主要错误修复。 维护生产/ qa版本的标签（可能是分支机构）。
制定干线政策并坚持下去。 一个例子可能是“主干必须始终没有错误地build立”。 或“中继线必须通过所有的unit testing”。 任何不能达到干线标准的工作都必须在分支机构完成。
不要使用代码更改提交格式更改
如果你想重构一个巨大的文件的空白（ Control + K + D ），那很好。 将格式更改与实际的逻辑更改分开提交。 如果你想在文件中移动函数，也是一样的。 提交与实际编辑分开的移动。
我始终坚持的关键概念之一是将相关的代码更改提交到一起 。 推论是不要在同一提交中提交不相关的代码更改 。 这意味着不要修复一个提交中的2个错误（除非它是相同的修复），并且不要在2个提交中的每一个中提交一半的错误修复。 另外，如果我需要添加一些新的增强function或某些其他工作所需的系统的不相关部分，我将分别进行增强（和第一个）。 这个想法是，任何人可能想要自己想要的改变（或者自己回滚）应该是一个单独的提交。 当需要合并或回滚中断function时，它将为您节省大量的麻烦。
已经提到很多，这里还有一些：
-
如果在源代码pipe理中有不需要的文件（例如configuration文件，编译文件等），请将其添加到忽略列表中 。 通过这种方式，您会注意到任何您忘记添加的文件，因为它总是会显示一个空文件列表，显示为SVN未知的文件。
-
添加一个提交后提交事件，该提交事件会将电子邮件发送到您的开发人员邮件列表 （或针对此目标的一个邮件列表 ），这些邮件列表与所做的更改相关，最好是针对该更新的补丁。
-
与你的bug跟踪器集成，以便引用提交显示错误/function请求与链接到差异。 像MantisBT这样的Bug跟踪器支持这一点。
-
考虑与持续集成 （例如CruiseControl.NET ），用于生成的NAnt和用于unit testing的NUnit / VS 集成 。 通过这种方式，一旦用户签入代码或按计划的时间间隔执行代码编译，unit testing运行，开发人员将获得该进程的反馈。 这也会提醒团队的其他成员，如果存储库已损坏（即不build立）。
那么，基本的：
- 在版本上启动QA之前创build标签
- 在风险变化之前创build标签（即大的重构）
- 为发布版本创build分支以冻结代码。
- 确保在开始工作之前，人们知道要更新，并在提交之前再次更新。
- SVN允许不同用户对同一个文件进行多次签出。 确保每个人都解决可能发生的任何冲突。
- 永远不要为多个用户使用同一个SVN帐户。 可怕的事情可能会导致。
人们给的答案很好。 在SVN的用户文档中总结了大部分的SVN最佳实践 。
重复：
- 设置你的仓库结构（你应该有在下面的主干，分支和标签的项目根）
- select你的政策重新分支（私人分行，每里程碑/释放/ bug分行等），坚持下去 – 我会build议更多的分支，而不是less，但不需要私人分支机构
- select你的策略重新标记 – 越多标签越好，但最重要的是决定你的标签命名约定
- select你的策略重新投入干线 – 保持干线尽可能“干净”，它应该随时释放
我想总结一下我坚持的最佳实践：
- 不要提交二进制文件 。 应该有单独的二进制文件库，如Nexus ， Ivy或Artifactory 。
-
应该有存储库结构 。 我个人使用以下存储库结构：
/trunk /tags /builds /PA /A /B /releases /AR /BR /RC /ST /branches /experimental /maintenance /versions /platforms /releases - 使用分支types的特定列表。 我的列表如下： 实验 ， 维护 ， 版本 ， 平台 ， 发布 。
- 使用特定types的标签 ：
PA（pre-alpha），A（alpha），B（beta），AR（alpha-release），BR（beta-release），RC（候选版本），ST（stable）。 - 尽量减less合并的必要性 。 当合并可能/鼓励时，应该有规则。
- 版本编号 。 应该有build立的版本编号方法来坚持。 通常在软件configurationpipe理计划这样的文档中描述，它是高级项目文档的一部分。 我个人使用复杂的版本编号方法。 根据这种方法，版本有以下模式： Nxx （维护/支持分支）， NMx （发布分支）， NxK （版本）， NMK （发布）。
- 尽可能频繁地提交 。 如果这样做比较困难（例如，为了实现function甚至编译代码而需要做太多的修改），应该使用实验分支。
- 树干应该包含最新的发展 。 例如，当select在哪里开发新的主要版本（ Nxx ）的应用程序，在中继线或分支机构中，总是应该为中继线做决定。 旧版本应该分成维护/支持部门。 它假定主要版本和它们的具体内容（架构，兼容性）之间有一个明显的区别，尽早出现 。
- 在发布分支严格的“不要打破”build设的政策 。 同时，只要可能有实验开发或需要合并问题解决的代码库，对主干不一定要严格。
- 使用svn：外部 。 它将允许模块化您的项目，build立透明的发布pipe理程序，划分和征服不同的function。
- 使用问题跟踪 。 您将能够在提交消息中指出问题引用。
- 禁用空提交消息 。 这可以使用预先提交钩子来完成。
- 定义你想要不断整合的分支 。 例如，我更喜欢使用持续集成的主干 ， 维护和发布分支机构。
- build立不同types的分支机构的持续整合政策 。 正如我刚才指出的那样，最严格的“不打破build造”规则适用于释放分支，而树干和维护分支有时可能被打破。 在干线/维护和发行分支上运行的检查列表也有区别。
你可以通过图表说明我的颠覆最佳实践的大纲，以图表说明我使用的软件configurationpipe理方法的主要原则。
有一件事我发现非常有用的是svn：external属性，这意味着你可以从其他仓库引用你自己的目录。 它提供了组织代码和数据的非常好的方法。 一些例子是：
- 如果你有不同的模块/库的代码库和你正在使用的引用。 这意味着您可以为每个可执行文件设置一个元数据存储库。 如果它是一个只使用几个模块的小型可执行文件，则不需要检出整个树。 这样做的效果是，您可以获得每个模块的SVN修订号。
- 将大型二进制数据（如编译版本的库）添加到代码库通常被认为是一个坏习惯，但它可以非常方便。 如果您只是将所有使用的库的所有版本添加到不同的存储库，则可以获得两个最好的世界。 您可以在您使用的库的版本中引用您的代码库。 在检查你的代码库的时候，你会得到代码和二进制文件。 然而，二进制文件存储在一个大的仓库，你不需要像你的源代码一样严格地备份，并且源代码库保持很小，只包含文本。
与bug跟踪软件集成 如果你使用的是Bugzilla ，你可以设置它，所以如果你的注释以“Bug XXXX”开头，你的SVN注释会自动添加为给定错误的注释，包括SVN Web界面的链接。
了解SVN的分支和合并工具和约定。
与其他团队成员合作的最佳方式是将工作分解为完整的开发特性/修复，然后分别在分支中进行个别更改。 然后，在完成/准备好/批准合并后，将更改合并回主干分行/主干。
通过这种方式，个人可以实现共同的目标（无论是在同一分支上还是在不同的分支上），而不会与其他变化相冲突。
你的里程可能会有所不同，这可能是只有两个左右的人矫枉过正。
如果您使用的是与SVN完美集成的良好工具，则会更容易。 这些可以很容易地看到改变了什么，然后提交全部或部分更改，并经常将工作副本更新到SVN中的最新版本。
我推荐龟SVN （如果您使用的是Windows）和Visual SVN （如果您使用的是VS）。
另请参阅您是否可以设置它，以便您在提交更改（通常还包括提交消息和更改的文件列表）时收到电子邮件或类似的通知。 像CVSDude这样的服务提供这一点。 我发现在更新我的工作副本之前知道更新已经完成，然后对该更新中包含的内容有所了解是很有帮助的。
除了分支政策等。 （其中一个尺寸绝对不适合所有），你应该有很好的承诺：
- 如果可能的话，承诺应该涉及一个单一的工作; 一个错误修复，一个新的function – 应该有一些“逻辑”来改变你所做的改变
- 该提交应该有一个描述性的评论，这将有助于您find它浏览存储库的历史。 大多数人build议在开始时写一个句子来描述整个提交和下面更详细的描述
- 如果可能的话，如果可能的话，你应该把这个提交和bug追踪系统联系起来。 Trac，Redmine等人 让您创build从错误到提交的链接，反之亦然，非常方便。
源控制的黄金法则： 提前入住，经常入住
有关如何组织您的存储库的提示：
- 你如何组织你的版本控制库？
- SVN书第5章仓库pipe理
- 存储库布局
在解决任何合并冲突之前，请向您的团队咨询其变更，或至less仔细查看差异。 要求他们自己检查合并的代码，以确保他们的添加不会在合并中丢失。
有一件事我看到，减less了提交失败，就是有好的预先提交脚本。 例如，您可以在提交更改之前运行任何unit testing。 这会导致承诺有点慢，但是通过避免踩到别人的脚趾并且必须道歉来节省时间。 当你有一个大的开发团队和非常频繁的提交时，这当然会变得更难pipe理。
与bug跟踪器和提交策略实施集成的一个例子可能是Trac的svn pre / post-commit挂钩脚本，如果提交消息没有在bug跟踪器中引用任何票据并向现有的注释添加注释，则脚本可以拒绝提交根据消息内容（例如，提交消息可能包含“修复＃1，＃2和＃8”，其中＃1，＃2，＃8是票号）。
SVN本身是一个好的开始，其他一些海报已经提供了一些关于最佳实践的伟大build议。
我唯一要补充的是，你应该把SVN与CruiseControl或TeamCity连接起来，以推动持续集成过程。 这将发送构build电子邮件，让别人知道什么时候有人打破了构build。
这将很早就知道谁跟随你的过程，谁不是。 可能会导致一些摩擦，但从长远来看，你的团队将会变得更好。
使用SVN的最佳做法：
-
当你第一次来到办公室打开你的Eclipse项目时，第一步就是更新你的项目。
-
在更新之后，开始你的工作。 当你完成你的编码，检查它是否正确，你的应用程序是否正常运行，没有任何例外。 一旦你确定你的代码工作正常，是时候提交代码了。
注意：在提交代码时，不要直接提交。 与服务器进行同步，检查所有需要提交的内容。 注意：不要提交整个文件夹一次。 因为您可能已经对文件进行了一些更改以满足您的需求，或者您可能已经删除了本地系统中的某些文件。 但是在服务器上的设置是不同的。 所以单独检查文件并提交代码。
-
不要直接提交/更新冲突文件。
-
什么时候重写和更新？
当你非常确定你不需要任何本地修改，并且想要完全更新服务器拷贝时。 记下一次，如果你做覆盖和更新，你将不会得到任何你的本地更改。
注意：不要保持项目不超过一天更新。 也不要保持代码没有承诺多天。
-
沟通谁在同一部门工作，并讨论他们每天做了哪些改变。
-
除非有某些原因，否则不要提交属性和configuration文件。 因为这些设置在服务器和云中会有所不同。
-
不要将目标文件夹提交到SVN中，只有源代码和资源文件夹必须在SVN存储库中维护。
-
当你丢失你的代码时，不要惊慌！ 您可以从SVN历史logging中找回更早的副本。
-
不要将项目签出到磁盘的多个位置。 在一个位置检查它并使用它。
-
精确评论每一个提交
-
不要打破（主线）build设！
-
一旦逻辑单元发生变化，立即提交
-
避免使用Subversion作为备份工具
-
稍微分支/合并尽可能
。
更多细节可以在SVN最佳实践中find。
DEV是否在分支上工作？
- 频繁地向你的分支提交
- 离散/模块提交给你的分支（ 见这里 ）
- 经常更新/合并来自主干。 不要重新坐在你的分支上
社区干线
- 应该始终build立/工作
- 每次提交一个问题（ 在这里再次看到 ）大多数情况下，您或其他人可以一次退出一个
- 不要将重构/空白变化与逻辑变化混为一谈。 你的队友将有一个艰难的时间提取你实际上做了什么
请记住，您提交的越多，模块化，离散和简洁，对您（或其他人）来说越容易：
- 逐渐退出更改
- 在不经过大量的空白和variables名称变化的情况下，直观地了解实际执行的操作。
- 当完成的工作与消息长度的比率较低时，提交消息意味着更多。
将其用于评论模板：
[任务/故事xxx] [未成年人/专业] [评论] [跟踪评论] [错误的URL]
