我刚开始使用SVN.我知道基本命令并理解基本原理.我想知道是否有人在团队环境中使用Subversion有任何提示或最佳实践.
我可以看到在提交代码时添加合理冗长的消息的好处,但还有其他我应该记住的事情吗？
感谢所有伟大的答案 - 他们帮了很多忙.
鼓励频繁提交. 不熟悉版本控制的队友可能觉得他们需要将代码保留在存储库中,直到"它正常工作".教导每个人尽早提交,并经常尽快找到问题.而不是保持代码"直到它工作,建议你的队友创建可能破坏主干的功能分支.这导致......
建立分支和标记实践. 除了功能分支外,还鼓励你的队友使用分支来修复大错误.在工作的开始和结束时标记主要错误修复.为生产/ qa版本维护标签(以及可能的分支).
制定干线政策并坚持下去. 一个例子可能是,"主干必须始终构建没有错误." 或"主干必须始终通过所有单元测试".任何不能满足主干标准的工作必须在分支机构完成.
不要在代码更改时提交格式更改
如果你想重组一个巨大的文件的空格(Control+ K+ D),那很好.提交格式更改与实际逻辑更改分开.如果要在文件中移动函数,也是如此.与实际编辑分开提交移动.
我一直坚持的一个关键概念是将相关的代码更改提交到一起.推论是在同一次提交中不提交不相关的代码更改.这意味着不要在一次提交中修复2个错误(除非它是相同的修复),并且不会在2次提交中提交一半错误修复.此外,如果我需要在系统的一个不相关的部分添加一些新的增强或某些东西,然后我需要进行其他工作,我会单独提交增强功能(首先).这个想法是,任何人可能想要拥有的任何变化(或自行回滚)应该是一个单独的提交.当需要进行合并或回滚损坏的功能时,它将为您节省大量的麻烦.
已经提到了很多,这里还有一些:
如果您在源代码管理中有不需要的文件(例如配置,编译文件等),请将它们添加到忽略列表中.通过这种方式,您可以注意到任何您忘记添加的文件,总是期望显示为SVN未知的文件的空列表.
添加一个帖子提交事件,该事件将向您的开发人员邮件列表(或针对此目标的一个特定的邮件列表)发送一封与提交的更改相关的电子邮件,最理想的是它的补丁.
与您的错误跟踪器集成,以便通过链接到差异来显示对提交/功能请求的提交.像MantisBT这样的Bug跟踪器支持这一点.
考虑与持续集成(例如CruiseControl.NET),用于构建的NAnt和用于单元测试的NUnit/VS 集成.这样,一旦用户签入代码或在计划的时间间隔内编译代码,就会运行单元测试,并且开发人员会获得该流程的反馈.如果存储库被破坏(即不构建),这也会警告团队的其他成员.
好吧,基础知识:
在版本上启动QA之前创建标记
在风险变化之前创建标签(即大型重构)
为已发布的版本创建分支以冻结代码.
确保人们知道在开始处理一段代码之前更新并在提交之前再次更新.
SVN允许不同用户对同一文件进行多次检出.确保每个人都能解决可能发生的任何冲突.
切勿对多个用户使用相同的SVN帐户.可能会导致可怕的事情.
人们给出的答案很棒.其中大部分内容在svn用户文档中进行了总结,以了解SVN的最佳实践.
重复:
设置您的存储库结构(您应该在项目根目录下有trunk,branches和tags)
选择你的策略重新分支(私有分支,每里程碑/发布/错误等分支)并坚持下去 - 我建议更多分支而不是更少,但不需要私有分支
选择您的策略重新标记 - 更多标记越好,但最重要的是决定您的标记命名约定
选择你的策略重新提交到trunk - 保持trunk尽可能"干净",它应该随时可以释放
我想总结一下我坚持的最佳实践:
不要提交二进制文件.二进制文件应该有单独的存储库,例如Nexus,Ivy或Artifactory.
应该有存储库结构.我个人使用以下存储库结构:
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
使用特定的分支类型列表.我的列表如下:实验,维护,版本,平台,发布.
使用特定类型的标签 :( PApre-alpha),A(alpha),B(beta),AR(alpha-release),BR(beta-release),RC(release release),ST(stable).
尽量减少合并的必要性.在合并是可行/鼓励的时候应该有规则,而在不合并的时候应该有.
版本编号.应该有坚定的版本编号方法.通常它在软件配置管理计划等文档中描述,它是高级项目文档的一部分.我个人使用复杂的版本编号方法.根据这种方法,版本的下列模式:NXX(维护/支持分支机构),NMX(发布分支),N×K个(构建),NMK(释放).
尽可能频繁地提交.如果它很难(例如,为了实现功能甚至编译代码时应该进行太多的更改),应该使用实验分支.
Trunk应该包含最新的开发.例如,当有选择在哪里开发新的主要版本(Nxx)的应用程序,在主干或分支中时,应该总是做出有利于trunk的决定.旧版本应分支到维护/支持分支.它假设主要版本之间存在明显的区别,并且它们的具体(架构,兼容性)尽可能早地出现.
在发布分支上严格"不破坏构建"策略.同时,对于trunk而言,它不一定是严格的,只要它可能有实验开发或代码库需要合并问题来解决.
使用svn:externals.它将允许模块化您的项目,建立透明的发布管理程序,划分和征服不同的功能.
使用问题跟踪.您将能够在提交消息中指出问题引用.
禁用空提交消息.它可以使用预提交钩子来完成.
定义要继续集成的分支.例如,我更喜欢对主干,维护和发布分支使用持续集成.
为不同类型的分支建立持续集成策略.正如我前面指出的那样,最严格的"不破坏构建"规则适用于发布分支,而主干和维护分支有时可能会被破坏.此外,在主干/维护和发布分支上运行的检查列表之间也存在差异.
您可以通过图表的形式找到我的颠覆最佳实践的概述,说明我使用的软件配置管理方法的主要原则.
我发现非常有用的一件事是svn:external属性,这意味着你可以将其他存储库中的目录引用到你自己的库中.它提供了组织代码和数据的非常好的方法.一些例子是:
如果您有一个单独的存储库,用于代码中不同的模块/库和您正在使用的库中的引用.这意味着您可以为每个可执行文件创建一个元库.如果它是一个只使用少量模块的小型可执行文件,则不需要签出整个树.这样做的结果是您获得每个模块的SVN修订版号.
将大型二进制数据(如编译版本的库)添加到代码存储库通常被认为是一种坏习惯,但它确实很方便.如果您只是将您使用的所有库的所有版本添加到不同的存储库,那么您可以获得两个世界中最好的.您可以在您使用的库的版本中引用代码库.检查代码库时,您将同时获得代码和二进制文件.但是,二进制文件存储在一个大型存储库中,您不需要像源代码那样严格备份,并且源代码存储库保持较小且仅包含文本.
使用与您的错误跟踪软件集成.如果你使用Bugzilla,你可以设置它,所以如果您的评论以"Bug XXXX"开头,您的SVN评论会自动添加为对给定bug的评论,包括指向您的SVN Web界面到该修订的链接.
京公网安备 11010802040832号 | 京ICP备19059560号-6 