你有任何提交政策吗？

Question

我的老板昨天宣布了一项新的提交政策，用于签入存储库。此策略适用于提交到主管/分支机构和分支机构 提交消息必须包含以下项：

• 原因（错误ID，项目ID或非功能更改）
• 审稿人姓名

提交后，我们还必须在CMS中创建更改博客条目。

我不是这个提交政策的忠实粉丝，因为当我在非生产性分支中做新的或实验性的东西时，我通常不需要审阅者。

您是否有任何提交政策，您必须遵循？

我认为仅仅因为Bug报告而改变生产分支是一个好主意，但是对开发分支的提交应该限制较少。

Answer 1

提前提交并经常提交。

我们实际上使用/ trunk作为开发和标签来分支不同的版本。只有结构性侵入性变化才会进入/分支。

我们积极使用标签进行生产和接受发布，因此我们可以轻松地追溯到时间。在主干中提交的任何内容都应该只有一条消息，描述提交更改或简要添加的内容。

我不是使用消息空间链接Bug ID的忠实粉丝，它仍然需要查找ID，在这种情况下你也可以在bug跟踪软件中查找并关闭它，这对我来说是一样的努力。

不是说我不喜欢任何svn集成： - 我们使用更多优质的自动化nant脚本来制作将它们分支在/ tags中的版本 - svn道具实际存储我们的版本号：p。 - 用于电子邮件通知和消息记录的钩子脚本（适用于复制粘贴发行说明）。

Answer 2

我们有许多策略，这些策略是通过Visual Studio的内部插件强制执行的。我们检查代码是否已编译，单元测试是否已成功运行。目前，我们还检查代码覆盖率并针对没有足够测试的代码发出警告。我们还进行各种一致性检查，并验证我们的变更管理系统中是否存在适当的任务，以便为所有变更提供可追溯性。

工具支持的优势很大，因为人们不应该尊重这些政策，但显然有一个缺点，因为这些检查需要时间来运行。但是，对于许多开发人员而言，如果没有适当的工具支持，很难执行标准。

Answer 3

由于你所提到的原因，评论家似乎毫无意义，因为并非所有事情都需要由其他人审核。

过去我们所拥有的唯一提交政策（我曾经工作过的地方）是包含一条注释，说明你改变了什么以及为什么，但这比其他任何事情更常见。

Answer 4

常见的提交策略是将错误ID与对trunk的提交相关联作为理由。有时，版本控制和错误跟踪系统配置为强制执行此策略。

Answer 5

我们的提交政策听起来有点像你的，只有我们不在任务分支上强制执行（任务分支就像开发人员的沙盒进行试验）。

我们的提交注释必须包含更改控件ID（新功能，增强功能）或问题ID（错误修复）。您还必须包含关于为何您做出此更改的简要说明;版本控制跟踪谁，什么，何时何地。

Answer 6

我的提交消息包括我在类中实现或更改的简短描述。

我在新代码上方的注释中添加的错误号和其他描述。我们将更改合并到标记分支时提交的提交消息中的ID。

每晚自动构建都会检查不同的功能和产品，以确保代码库是稳定的。

但最后我认为你不能对新的或改变的类有太多的描述，但在提交之前你必须做太多的策略。审阅者的姓名是我不会在提交消息中添加的内容。

请注意，您有时必须解决您在2年前实施的代码。然后你很高兴提交的消息不像“调试后更新”。

Answer 7

我们为每个已发布的主要版本的软件提供分支，但仍然受到积极支持。检查任何这些分支都需要一个错误ID - 这由scmbug强制执行，这不仅会检查注释是否以错误ID为前缀，而且还会在错误数据库中查找此错误，确保错误被分配给提交者，并可能检查其他标准（例如，“修复分支”字段是被提交的分支）。

其中一种产品更有可能以尴尬的方式失败，并且签到此功能不仅需要错误ID，还需要代码审查。但是，代码审查的标准是在我们的错误数据库中处理的 - 我们为此提供了自定义字段，并且在审核之前无法接受和关闭错误。对我来说，这从概念层面起作用 - 最好检查被认为在未经审核的情况下工作到存储库的代码，然后重新打开错误并在必要时更改它，而不是等到提交直到你确定它已准备好发布。

除此之外，没有针对主干的明确策略（当然，通常在不破坏构建的情况下检查的一般原则，包括良好的描述性提交消息，原子地检查工作单元仍然适用）。