我想知道是否有任何其他因素需要考虑使用Subversion的标准做法.
我所拥有的是:
/ tags/trunk和/ branches的目录结构
所有工作都在干线完成,不会破坏功能
在进行主要结构更改或添加功能以破坏核心功能时进行分支(视首选项而定)
标签包含稳定版本
始终在开始工作之前执行更新
在一天结束时/添加功能时提交更改
提交说明包含相关说明
基于功能提交 - 不进行全面提交
我对于在当天结束时以及添加功能时提交的规则存在冲突.我说在一天结束时确保存储库尽可能最新.但是,当天结束时的代码可能是不完整/中断功能.但是,只有在功能完成时提交才会导致过时/冲突？
对于我的任何想法以及我错过的任何想法,我都很感激你.
谢谢!
Cri*_*ll 6
更多注意事项:(尽量不重复已经说过的话......)
分行:
除了上面提到的大块功能开发的分支外,您还可以在需要处理发布后修复时进行分支,同时在主线/主干上进行并行工作.
如果您使用长期存在的分支而不合并到主线开发,则定期反向合并.这将有助于与后备箱开发保持同步,并最大限度地减少大爆炸合并的复杂性.
注意你为分支命名的方式.我们尝试在基于它的里程碑之后命名分支.如果名称是自我解释的,当您需要快速差异或报告或甚至在浏览某些内容时它会有所帮助.
因为在SVN中分支是一个廉价的副本,我们尝试始终分支在项目目录的根目录(如果它是文件夹主干本身,那么分支将离开主干) - 这避免了以后混淆谁分支到哪里和避免必须运行命令才能找到它.如果你需要从分支机构结账,那么分支机构的每一个标签都可供您使用 - 如果您碰巧需要它.
提交:
我经常和逻辑块投票提交提交,因此您可以通过常见的提交消息绑定相关文件.这非常适合当你想要一个日志而且报告是在一堆文件中完成的,所有这些文件都与相关的注释完全捆绑在一起.
我投票支持频繁提交,如果不是每天.这是一种心态.一旦你看到早期提交的好处(当然在开发人员检查了基本的编译错误并在开发框中运行了单元测试之后),你会很乐意捕捉到那些早期的bug /构建问题.如果您计划运行每晚构建或使用持续集成工具,那么最好让人们尽早提交,以帮助深入了解集成的工作流并对其进行测试.
标签:
您应该在提交之前始终进行更新,以防止可能与其他人提交的其他提交冲突以及痛苦的合并.
此外,每个提交都应该包含一些有意义的内容,例如错误修正或新功能,或者对现有提交进行一些改进,这些内容可以在日志消息中有意义地描述.源控制工具不是备份工具,因此应避免在没有有意义内容的情况下进行"每日结束"提交.