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