我想知道使用Subversion的标准做法是否还有其他因素要考虑。
我所拥有的是：
/ tags / trunk和/ branches的目录结构
所有工作都在干线完成，不会破坏功能
在进行重大结构更改或添加功能以破坏核心功能（根据需要）时进行分支
标签包含稳定版本
始终在开始工作前执行更新
在一天结束时/添加功能时提交更改
提交说明包含相关说明
基于功能提交 - 不进行全面提交
我对于在当天结束时以及添加功能时提交的规则存在冲突。我说在一天结束时确保存储库尽可能最新。但是，当天结束时的代码可能是不完整/中断功能。但是，只有在功能完成时提交才会导致过时/冲突？
我很感谢你的批评我的任何想法以及我错过的任何想法。
谢谢！
答案 0 :(得分：6)
还有一些注意事项:(已经尽力不重复已经说过的话了。）
分支机构：
除了为上面提到的大块功能开发进行分支外，您还可以在需要处理发布后修复时进行分支，同时在主线/主干上进行并行工作。
如果您使用的是长期存在但未合并到主线开发的分支，则定期反向合并。这将有助于与后备箱开发保持同步，并最大限度地减少大爆炸合并的复杂性。
注意您为分支命名的方式。我们尝试在基于它的里程碑之后命名分支。当你需要快速差异或报告，或者甚至在浏览某些内容时，如果名称不言自明，它会有所帮助。
由于在SVN中分支是一个廉价的副本，我们尝试始终分支在项目目录的根目录（如果它的文件夹主干本身，那么分支将离开主干） - 这避免了以后的混淆关于谁在哪里分支并避免必须运行命令来找到它。如果你需要从分支机构结账，那么分支机构的每一个标签都可供您使用 - 如果您碰巧需要它。
提交：
我经常在逻辑块中投票提交提交，因此您可以通过公共提交消息绑定相关文件。这非常适合当你想要一个日志而且报告是在一大堆文件中完成时，所有文件都与相关的评论完全相关。
我投票支持频繁提交，如果不是每天。这是一种心态。一旦你看到早期提交的好处（当然在开发人员检查了基本的编译错误并在开发框中运行了单元测试之后），你会很乐意捕捉到那些早期的bug /构建问题。如果您计划运行每晚构建或使用持续集成工具，那么最好让人们尽早提交，以帮助深入了解集成的工作流并对其进行测试。
标签：
答案 1 :(得分：5)
在提交之前，您应该始终进行更新，以防止可能与其他人提交的其他提交冲突以及痛苦的合并。
此外，每个提交都应该包含一些有意义的内容，例如错误修正或新功能，或者对现有提交进行一些改进，这些内容可以在日志消息中有意义地描述。源代码管理工具不是备份工具，因此应避免在没有有意义内容的情况下进行“每日结束”提交。
答案 2 :(得分：4)
如果你是SVN的新手，那么一个好的（免费）资源是SVN Book（死树拷贝也可以从O'Reilly购买）。
答案 3 :(得分：4)
如果“功能”需要超过几（4-6）小时才能完成，我会
答案 4 :(得分：3)
“但是只有在功能完成后提交才会导致过时/冲突？”
如果变化太大而你担心这一点，那么你可能应该分支。这将允许您在不破坏构建的情况下进行增量工作时进行较小的提交，并在合并到主干后留下明确的历史记录。
答案 5 :(得分：3)
我会尝试尽可能多地提交。为此，您必须确保您编写的代码尚未使用，或者所有测试都通过。如果你保持这两种模式中的一种（后者比前者好得多），那么当你不能提交时，你不必担心那些大的时期。
TDD在这方面非常有帮助。
答案 6 :(得分：2)
分支机构是进行重大变革的好主意。如果正在同时更新主干，偶尔会将主干合并到分支以保持分支更新。
提交相关更改的原子集。不要做一个大的提交与无关的变化。这使得跟踪特定更改变得更加容易。
您可以对同一来源进行多次检查 - 如果尝试不相关的更改，则非常有用。
避免提交损坏的代码，代码失败的测试或其他未解决的问题。
答案 7 :(得分：0)
源代码控制工作流程有很多变化。我们使用的是您在帖子中描述的内容的扩展。您的工作流程足以进行微小的修改，但如果您有多个团队处理相当复杂的不同问题，则不会这样做。
我们所做的是为每个团队分支，而不是团队可以提交给团队（项目）分支。每个团队还负责通过合并主干到分支来同步团队分支与主干，最好是在每次提交到主干之后。项目完成后，分支将合并回主干（重新集成）并删除。
这种方法分支 - 合并...合并 - 合并 - 删除对我们来说效果很好
答案 8 :(得分：0)
我最近参与了改进我工作的公司使用的软件配置管理（SCM）技术。我们发现“分支开发”和“分支发布”都很有效。
我发现有关SCM模式/标准程序的好书是“软件配置管理模式：有效的团队合作，Berczuk和Appleton的实际整合”。