一个CL描述是做了什么更改以及为什么的公开记录。 它将成为我们版本控制历史的永久组成部分，多年来除你的评审者以外，还可能有数百人会阅读它。 将来的开发者将会基于它的描述来搜索你的CL。 将来可能会有人由于没有现成的细节，而根据他模糊的记忆来寻找你的改变。 如果所有重要的细节都在代码中而不是描述中，那么他们将很难定位你的CL。
CL描述的第一行应该是对CL正在做的具体工作 的简短总结，紧跟一个空行。
这是应该出现在版本控制历史摘要中的内容，它应该提供足够的信息，以便将来搜索代码的人必阅读整个CL或完整的描述来理解CL实际上“做了”什么，或者它与其他CLs有什么不同。也就是说，第一行应该是独立的，允许读者更快地了解代码历史。
其余描述应该是具有丰富的内容。它可能包括对正在解决的问题的简要描述，以及为什么这是最好的方法。 如果这种方法有任何缺点，就应该提到。将相关的背景信息（例如bug数目，基准测试结果），以及设计文档的链接。 如果你想加一些链接来指向其他内容，请注意未来的阅读者可能因为没有权限看不到这些内容，所以尽可能地把上下文都写在CL中以方便评审者和未来CL的阅读者。 另外，即使是很小的CL也值得关注细节。请将来龙去脉放入CL中。
"Fix bug"是一个不充分的CL描述。是什么bug？你是怎么修复它的？ 其他一些类似的不好的CL描述:
也有一些真实的CL描述，虽然简短，但没有提供任何有用的信息。
前几个词描述了CL描述实际做了什么。其余描述在说明解决的问题，为什么这是一个好的方案，以及具体实现的细节。
第一行描述了CL做了什么，以及它是如何与过去发生变化的。 其余的描述将讨论具体的实现、CL的来龙去脉、解决方案的不理想以及未来可能的方向。 它同样是解释为什么要进行这个修改。
第一句描述了实际做了什么。其余的描述解释了为什么要进行更改，并给了reviewer很多背景。
虽然有些CL是工具生成的，但是只要可能，CL的描述也应该遵循本规范，始终保持言简意赅，CL的描述主体应该包含有助于未来查阅代码的人理解整个CL作用的有用信息。
在Review期间CL可能会经历重大改变。在提交CL之前，有必要review CL描述，以确保描述仍然反映CL所做的事情。