在提交消息中引用错误/问题是否被视为良好做法?


11

我正在一个项目中,在该项目中我们设置了源代码控制,可以在Bug跟踪器中自动编写注释。我们只需在提交消息中写入错误问题ID,然后将提交消息作为注释添加到错误跟踪器。

我只能看到这种做法的一些弊端。如果将来某个时候源代码与错误跟踪软件分离(或者报告的错误/问题以某种方式丢失)。或者,当某人正在查看提交历史记录但无法访问我们的错误跟踪器时。

我的问题是在提交消息中包含错误/问题引用是否被认为是一种好习惯?还有其他缺点吗?

Answers:


10

我们采用了这种做法,对我们来说效果很好。版本控制系统(VCS)与我们使用的其他系统之间的紧密集成(例如持续集成,错误跟踪器等)非常有价值。如果将来有任何更改,我们当然必须评估副作用,包括VCS和错误跟踪系统之间的链接。

总的来说,我认为这是一种好的做法。对于某些跟踪系统,还有其他可用的选项和工具,例如Subversion(SVN)的bugtraq属性。这表明相当多的人认为这种做法有价值。


13

如果您想真正确保即使将来使用其他错误跟踪器或错误跟踪器数据以某种方式消失,也不会丢失任何信息,为什么不将问题ID 有关错误的简短说明都放入其中提交消息?

修正错误#123:应用程式在登入后当机

然后,您仍然具有从提交历史记录到错误跟踪器的链接-如果错误跟踪器不可用,您仍然可以在历史记录中看到此特定错误的含义。


我们实际上是这样做的,因此不必每次浏览提交历史时都切换到Bug跟踪程序。
Christian P

好吧,那我就照原样了。海事组织,这是最好的方式!
Christian Specht

1
是的,很好。无论如何,那是我的假设。仅凭错误/问题ID不足以我的经验。查看提交日志,您仍然想要查看每个提交的含义,例如,此代码更改的主要原因是什么。有时,提交消息更多地在技术方面,而错误跟踪系统的文本则更多地面向软件用户。
曼弗雷德

通常这也是我工作的标准做法,我认为这是正确的方法。
2011年

+1总是这样做!我刚刚进行了一个项目维护,该项目充满了诸如“这可能是Bug 5423的原因”之类的宝石。我们无法访问其Bug跟踪器。
Kryptic 2011年

2

这是非常常见的做法,我发现它非常方便。我使用TRAC,因此我可以阅读代码历史记录并导航到驱动更改的任务,或者阅读任务历史记录并导航到代码更改。

“如果将来某个时间……”如果您将代码与错误跟踪器分开,那么旧的修订历史记录可能就不再引起您的兴趣。


2

我也使用这种做法,我认为这是一种很好的做法。但是除了问题ID,我还添加了有关错误/功能的简短描述(通常是错误跟踪系统的标题)。这通常可以节省时间,因为我不必在Bug跟踪系统中查找(因为我已经知道了更改),而且就像您所说的那样,如果我以某种方式丢失了Bug跟踪系统,也不会完全丢失。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.