我的老板昨天宣布了一项新的提交政策，用于签入存储库。此策略对头部/主干和分支的提交有效。
提交消息必须包含以下内容：
提交后，我们还必须在我们的 CMS 中创建一个更改博客条目。
我不是这个提交政策的忠实拥护者，因为当我在非生产性分支中做新的或实验性的东西时，我通常不需要审阅者。
您是否有任何必须遵守的提交政策？
我认为仅由于错误报告而更改生产分支是个好主意，但提交到开发分支的限制应该更少。
【问题讨论】：
尽早提交并经常提交。
我们实际上使用 /trunk 作为开发和标签来分支不同的版本。 /branches 只有结构性的侵入性变化。
我们积极使用标签进行生产和验收发布，因此我们可以轻松地回到过去。在主干中提交的任何内容都应仅包含一条消息，描述提交更改或添加的内容。
我不太喜欢使用消息空间来链接错误 ID，它仍然需要查找 ID，在这种情况下，您也可以在错误跟踪软件中查找并关闭它，这对我来说几乎是一样的努力。
并不是说我不喜欢任何 svn 集成： - 我们使用更多的自动化 nant 脚本来制作在 /tags 中分支的版本 - svn props 实际上存储了我们的版本号：p。 - 用于电子邮件通知和消息记录的挂钩脚本（非常适合复制粘贴发行说明）。
【讨论】：
我们有许多策略，这些策略是通过 Visual Studio 的内部插件强制执行的。我们检查代码是否编译并且单元测试是否已成功运行。目前，我们还检查代码覆盖率并对没有足够测试的代码发出警告。我们还进行各种一致性检查并验证我们的变更管理系统中是否存在适当的任务，以便为所有变更提供可追溯性。
工具支持的优势是巨大的，因为人们并不能真正尊重政策，但显然存在一个缺点，而且这些检查需要时间来运行。但是，对于许多开发人员来说，如果没有适当的工具支持，就很难执行标准。
【讨论】：
由于您提到的原因，审稿人似乎毫无意义，因为并非所有内容都需要他人审阅。
过去，我们唯一的提交政策（我曾经工作过的地方）是包含一条评论，说明您更改了什么以及更改原因，但这比其他任何事情都更符合常识。
【讨论】：
一个常见的提交策略是将错误 ID 关联到主干的提交作为理由。有时，版本控制和错误跟踪系统配置为强制执行此策略。
【讨论】：
我们的提交政策听起来有点像你的，只是我们不会在任务分支上强制执行（任务分支就像开发人员的试验沙箱）。
我们的提交 cmets 必须包含更改控制 ID（新功能、增强功能）或问题 ID（错误修复）。您还必须简要说明为什么您做出此更改；版本控制跟踪谁、什么、何时和何地。
【讨论】：
我的提交信息包括一个简短的描述我在类中实现或更改的内容。
我在新代码上方的注释中添加了错误编号和其他描述。当我们将更改合并到标记的分支中时，我们在提交消息中放置的 ID。
每天晚上，自动构建都会检查不同的功能和产品，确保代码库稳定。
但最后我认为你不能对新的或更改的类有太多的描述，但在提交之前你必须做太多的策略。审阅者的名字是我不会放在提交消息中的。
想想你有时不得不理解你在 2 年前实现的代码。然后你会很高兴提交消息不像“调试后更新”。
【讨论】：
对于每个已发布的主要软件版本，我们都有分支，但仍受到积极支持。检查这些分支中的任何一个都需要一个错误 ID - 这是由 scmbug 强制执行的，它不仅会检查评论是否以错误 ID 为前缀，还会在错误数据库中查找此错误，确保已分配提交给提交者，并可能检查其他条件（例如，“分支中的修复”字段是提交到的分支）。
其中一个产品更有可能以令人尴尬的方式失败，并且检查此问题不仅需要错误 ID，还需要代码审查。但是，代码审查的标准是在我们的错误数据库中处理的——我们为此有自定义字段，并且在审查之前无法接受和关闭错误。对我来说，这从概念层面上是有效的——最好检查那些被认为可以在未经审查的存储库中工作的代码，然后重新打开错误并在必要时对其进行更改，而不是推迟提交直到你确定 已准备好发布。
除此之外，没有明确的主干策略（当然，在不破坏构建的情况下经常签入的一般原则，包括良好的描述性提交消息，原子地签入工作单元仍然适用）。
【讨论】：