svn - Subversion 的标准实践

Question

我想知道使用 Subversion 的标准实践是否还需要考虑任何其他因素。

我拥有的少数是:

• /tags/trunk 和/branches 的目录结构

• 所有工作都在主干中完成，不会破坏功能

• 当进行重大结构更改或添加破坏核心功能的功能时(根据偏好)进行分支

• 标签包含稳定版本

• 开始工作前务必执行更新

• 在一天结束时/添加功能时提交更改

• 提交注释包含相关描述

• 根据功能进行提交 - 不要覆盖提交

对于在一天结束时和添加功能时提交的规则，我的想法很矛盾。我说归根结底是为了确保存储库尽可能是最新的。然而，最终的代码可能不完整/破坏功能。但是，仅在功能完成时才提交可能会导致过时/冲突？

我很感激您对我的任何想法以及我错过的您的任何想法的批评。

谢谢!

Answer 1

更多注释:(已尝试不重复已经说过的内容..)

分支机构:

1. 除了上面提到的针对大量功能开发的分支之外，您还可以在需要处理发布后修复时进行分支，同时在主线/主干上进行并行工作。

2. 如果您使用的分支长期存在而没有合并到主线开发，请定期进行反向合并。这将有助于与主干开发保持同步，并最大限度地减少大爆炸合并的复杂性。

3. 注意分支的命名方式。我们尝试根据分支所基于的里程碑来命名分支。当您需要快速比较或报告时，甚至在浏览某些内容时(如果名称是不言自明的)，它会有所帮助。

4. 由于在 SVN 中，分支是一个廉价的副本，因此我们尝试始终在项目目录的根目录下分支(如果是文件夹 trunk 本身，则分支将脱离 trunk)——这可以避免以后出现困惑关于谁在哪里分支，并且避免必须运行命令来查找它。如果您需要从分支 check out 东西，则分支下的所有内容都可供您使用——如果您碰巧需要的话。

提交:

1. 我经常以逻辑 block 的形式对提交进行投票，这样您就可以通过公共(public)提交消息将相关文件联系起来。当您需要日志并且报告是分块完成的，并且所有文件都与相关注释整齐地捆绑在一起时，这非常有用。

2. 我投票支持频繁提交，即使不是每天。这是一种心态。一旦您看到早期提交的好处(当然，在开发人员检查了基本编译错误并在开发框中运行了单元测试之后)，您会很高兴发现这些早期错误/构建问题。如果您计划每晚运行构建或使用持续集成工具，那么最好让人们尽早提交，以帮助深入了解集成的工作流并对其进行测试。

标签:

1. 确定版本命名约定 - 尽管这看起来微不足道，但拥有良好的标签名称会有所帮助。还要确保标签的提交注释准确说明了您标记此版本存储库的原因。我们仅在进行里程碑构建时添加标签，因此在我们的例子中，我们将标签提交消息与我们用于给定构建的连续构建号(巡航构建标签)进行映射。它还有助于定义版本编号方案和字段，以便您可以将它们用于标签。