您可以将变更日志视为一个概念上的“撤销列表”，它说明了早期版本与当前版本的不同之处。人们可以看到当前版本；他们不需要变更日志来告诉他们其中包含什么。他们希望从变更日志中得到的是对早期版本如何不同的清晰解释。变更日志中的每个条目描述一个单独的更改，或者属于一起的最小一批更改，也称为变更集。
最好用一个标题行开始变更日志条目：一个完整的句子，总结了变更集。如果您将变更日志保存在 VCS 中，这应该是一个要求，因为以缩写形式显示变更日志的 VCS 命令，例如 git log --oneline，会特别处理标题行。（在 ChangeLog 文件中，标题行跟在说明更改作者和安装时间的行之后。）
在变更日志条目的标题行之后，是对整个更改的描述。这应该尽可能长，以提供清晰的描述。特别注意那些不容易从差异或修改过的文件和函数的名称中收集到的变更集方面：更改的整体思路和必要性，以及对不同文件/函数所做的更改之间的关系（如果有）。如果更改或其原因在某些公共论坛（例如项目的议题跟踪器或邮件列表）上讨论过，最好在更改的描述中总结该讨论的要点，并包含指向该讨论或议题 ID 的指针，以便那些想要完整阅读的人可以阅读。
解释新代码的各个部分如何与其他代码协同工作的最佳位置是在代码中的注释中，而不是在变更日志中。
如果您认为某个更改需要解释为什么需要此更改——也就是说，旧代码存在什么问题才需要此更改——您可能是对的。请将解释放在代码中的注释中，人们在看到代码时就会看到它。这种解释的一个例子是，“此函数以前是迭代的，但在 MUMBLE 是树时失败了。” （尽管如此简单的原因不需要这种解释。）
其他类型的更改解释的最佳位置是在变更日志条目中。特别是，注释通常不会说为什么某些代码被删除或移动到另一个位置——这属于进行该操作的更改的描述。
在对更改进行自由文本描述之后，最好根据文件列出您更改的实体或定义的名称，以及每个文件中更改的内容。请参阅变更日志的风格。如果项目使用现代 VCS 来保存变更日志信息，如变更日志中所述，则严格来说，不必明确列出已更改的文件和函数，在某些情况下（例如在许多地方进行相同的机械更改），甚至会很繁琐。您可以决定是否允许项目的开发人员在日志条目中省略已更改的文件和函数的列表，以及是否允许在某些特定条件下省略。但是，在做出此决定时，请考虑为每次更改提供已更改实体列表的以下好处
由于这些原因，为每次更改提供修改过的文件和函数的列表会使变更日志更有用，因此我们建议在可能和实际的情况下包含它们。
也可以通过运行脚本来生成命名修改过的实体的列表。这样的一个脚本是 mklog.py（用 Python 3 编写）；它被 GCC 项目使用。Gnulib 提供了此类脚本的另一个变体，称为 vcs-to-changelog.py，它是 vcs-to-changelog 模块的一部分。请注意，这些脚本目前支持的编程语言少于 Emacs 提供的手动命令（请参阅变更日志的风格）。因此，上述从 VCS 提交历史生成 ChangeLog 文件的方法（例如通过 gitlog-to-changelog 脚本）通常会产生更好的结果——前提是贡献者坚持提供良好的提交消息。