提问人:Pekka 提问时间:3/2/2010 更新时间:3/2/2010 访问量:1241
在 Subversion 提交消息中使用 markdown - 有什么想法吗?
Using markdown in subversion commit messages - any thoughts?
问:
我喜欢在我的 Subversion 提交消息中使用 markdown 表示法,计划有一天创建一个“日志”函数,它将在 HTML 页面中输出提交消息,这与 Trac 的“历史”视图不同。(如果 Trac 当时还没有 markdown 插件来达到这个目的。
谁能想出任何反对的理由?
唯一想到的特别之处在于它们的使用,但它们应该像其他任何东西一样逃脱,所以这应该不是问题。backticks
答:
3赞
Esteban Küber
3/2/2010
#1
我使用 trac,它对所有内容都使用 Wiki 标记(我刚刚检查过,它也用于提交日志)。我主要使用 or 用于列表,并且 trac 正确显示它们。*
-
在下一次提交时,我将查看它是否接受反引号(或 和 ,Wiki 标记也接受),但它很可能会接受。{{{
}}}
我看不出你不应该在自己的日志上使用 Markdown 的理由,并且可能会为您的项目管理和错误/问题跟踪系统创建一个小插件。
评论
2赞
chelmertz
3/2/2010
Trac 真的很好,因为诸如“修复 #42”之类的提交消息成为指向票证的链接,“修复 [151] 中引入的错误”成为指向另一个变更集的链接。
3赞
John Feminella
3/2/2010
#2
谁能想出任何反对的理由?
是的:提交应该是简单明了的文本,以鼓励最少的提交消息。如果你需要这种格式,你的提交消息没有清楚地解释消息的目的。一般来说,提交消息应该简短、简洁地描述更改,不超过两三句话。如果需要更多细节或上下文,他们可以引用外部问题(例如“修复问题 #184 图形错误”)。
如果这不仅仅是个人偏好,而且您的提交确实需要大量的细节和格式来解释,那么它们可能太大了,应该分解成更小、更容易消化的块。
评论
2赞
Esteban Küber
3/2/2010
我有时会在修复相关错误或在单次提交中实现相关功能时使用列表。
0赞
Lou Franco
3/2/2010
同意。我的源代码管理和 bug db 是集成的,因此我可以在提交消息中引用案例,并且它们会自动链接。我喜欢给出案例#和快速描述。很容易在列表中注视,如果我需要更多信息,可以向下钻取。
1赞
Pekka
3/2/2010
@John好的观点,但我有时想简要介绍一下变化(例如 现在需要第二个参数是 ),也具有构建变更日志的长期目标。但是,票务系统可能是更好的选择。无论如何,我喜欢做一些格式化,即使是简洁的日志消息,例如,对于重要的事情,或者*粗体**/*斜体。xyz()
int
function_names()
0赞
John Feminella
3/2/2010
我认为相应地分隔作为代码的短语是可以的,但更多的东西可能是我会划清界限的地方。例如,我编写了诸如“验证指针返回正确引用”之类的提交,因为如果没有反引号,“this”指的是什么就不明显了。this
2赞
Craig McQueen
3/2/2010
MarkDown 的伟大之处在于它的“原始”形式仍然非常可读。因此,即使你正在查看 Subversion 日志的“原始”日志,而没有被 MarkDown 处理,它也不会真正妨碍你。
上一个:在PHP中检测整数?
下一个:正则表达式可匹配无限数量的选项
评论