我正在讨论的做法是：您的项目/产品有一个针对错误，功能等的票务系统。还有源代码管理。然而，似乎总是有理由试图将这两者结合在一起。有些地方不想要没有票号的签到。一些开发商店对于每张签到都有票的要求比较宽松，并且会在没有附上票号的情况下进行小额签到或两张幻灯片。
问题：是什么让这种做法如此有用？
我在职业生涯的各个地方都看过这种做法。这在Microsoft的Team Foundation Server等产品中尤为明显。我在IBM看到了他们自己开发的源代码管理系统CMVC。我已经看过Mingle和SVN，或者SVN和Redmine，您可以通过简单地将票号放在提交消息中来将票证与票证相关联。在所有这些地方，我真的没有发现它对我自己的工作有用，所以我意识到它应该在某个地方有用。
答案 0 :(得分：4)
如果您在签到时有票号，可以参考错误报告，了解编辑的原因。这通常与实际编辑本身一样重要，如果不是更重要的话。
答案 1 :(得分：2)
我发现执行此操作最有用的方面是在查看其他开发人员提交时的提交。存储库设置为每个提交发送一封电子邮件，其中包括提交文本和差异。回顾这一点对于跟上中型项目的进展非常重要。
签入文本通常会解释 已被更改但为什么，如果需要，“票证”可以填写您。
有时，问题跟踪器包含有关如何处理难题的冗长讨论，阅读它可以让您了解为何做出某些决策。这很有价值。
当然，这种用途因项目而异。
答案 2 :(得分：1)
它代替了良好的需求规范或需求可追溯性，非常方便。在进行考古学解释系统的当前状态时很有用。
答案 3 :(得分：1)
它告诉你：
答案 4 :(得分：0)
我们这样做，但不是虔诚的。我们在内部使用Trac，一旦您开始使用该链接，您就可以查看故障单并轻松查看为其执行的变更集。对于复杂的票证，这是非常有用的，特别是如果需要任何类型的代码审查。
通过这种做法可以让您了解更改原因的背景知识，实际上我们发现我们并没有那么多地使用它。但它很高兴，您需要做的就是在提交消息中提及票号。
答案 5 :(得分：0)
无论您是提供商业支持还是运行开源项目，都有很多价值。如果您正在支持您的产品，并且有人要求报告错误，您可以检查是否已报告错误，是否已报告错误，是否有适当的修复，测试等等。在开源项目中，人们可能正在运行直接从源代码控制中提取的软件版本，如果有错误修复或他们想要的功能，他们可以检查问题跟踪器并找出它是否在更新版本中修复。
答案 6 :(得分：0)
如果您可以将两者结合在一起可能很有用，例如，我们有一个接收提交消息的脚本，如果您提供了问题编号，则会添加到错误跟踪票证中。它对管理者和控制狂有用，因此他们通过阅读消息而不是直接打扰开发人员来在一个地方跟踪问题状态。
答案 7 :(得分：0)
告诉你谁做了修复：o）