comment是版本管理中非常重要的内容,尤其是在经年累月的大型项目中,铁打的项目,流水的SE,哪怕只言片语的留下,对后来者问题的对应很多时候都能起到重要作用,这篇文章用来讲解git中如何进行comment的管理.
为什么需要comment
为什么需要comment,理由有很多:规范,可读,可维护,bug分析等等。很多人可能在新入一个大型项目时候进行原因调查时候都有很多障碍,尤其是业务不清晰,然后再加上经年累月的bug修改,导致目前的代码已经面目全非的可能性很多,如果有点comment,那就是绝望之中的一根稻草,自然十分重要。
以前曾经碰到过一个很有趣的case,逻辑判断的==被写成了=,这样就变成恒真的一个判断了,跟删除无异,本来准备修改,无意之中发现此行是刻意被修改的,而且提交了一行comment,内容大概是"bug fix",这么难解的comment虽然让人望而却步,但是总提供了一点信息:这是不可以随便修改的,要么把此行删除,要么别动它。
comment使用实践
好记性不如烂笔头,大型项目中comment最好要跟redmine/trac/bugzero等工具结合起来,不同的项目一般都有自己的规范,比如:
项目 | 说明 |
---|---|
原则1 | 提供bug追踪工具中此次修改的详细信息的Ticket号,以确认更详细信息 |
原则2 | 同时将简单将修改原因的重点信息列出,便于确认 |
原则3 | 尽量1行之内,便于整体确认 |
以下将通过实际的例子操作来展示如何进行comment的管理。
当前状态
使用上篇文章创建的分支,因为其中已经有若干commit附带若干comment