Git的提交说明写下以后，后来得到的补充信息仍可由notes关联到该提交。git-notes手册在DESCRIPTION中明确，这种附注附着于对象，却不触动对象本身；补充commit message而不改变原commit，是其典型用途。[1] 因而，这里增加的是一份与对象相联系的资料，不是将原提交里的消息重新写一遍。

这种分开首先反映在资料的查找位置。默认的附注引用是refs/notes/commits，手册也允许使用其他notes引用。原提交有自己的消息，notes则从选定的附注引用取得内容。即使屏幕把两者接着显示，二者的来源仍不同；“显示在同一条日志附近”不能据此解释成“存进了同一个提交对象”。

日志的文字排版保留了这层区别。手册说，附注与原消息一样缩进，但其前面另有不缩进的Notes加引用名标题；使用默认refs/notes/commits时，标题简写为Notes。这里的标题既标记附注区，又能在非默认引用的情形下指出所显示的附注来自哪里。引用名不是补充消息正文的一部分，原提交消息也没有因这个标题而变成附注。

DISCUSSION进一步说明内部的对应关系：commit notes是保存额外信息的blob，notes引用通常是一条分支，其中类似文件的路径对应被注释对象的名称。路径中还可插入目录分隔，原文将此联系到性能方面的考虑。附注的内容、用于寻找内容的路径，以及被描述对象的名称，因此分别承担不同角色；路径里的对象名用于建立对应，并不是说路径本身就是附注文字。

附注的历史也在这个位置形成。官方写道，每一次notes变化，都会在指定的notes引用处产生一个新提交。这条记录追踪的是附注如何变化，与此前被附注的那次提交各有对象。一次原提交可以成为后来补充信息所指向的对象，而那些补充的先后变化由notes一侧的历史表达，无须把原提交当成每次补充都重新生成的文本容器。

“通常是一条分支”还不是唯一存储情形。手册另允许notes引用直接指向一个tree对象。这个例外使引用的用途与其具体指向类型不能完全合并：它仍为附注资料提供入口，但不能仅凭notes这一用途，就断言所有附注引用必定采用同一种分支形态。

当同一份附注进入补丁文字时，又有另一种载体位置。手册对format-patch的说明是，附注可以作为三条连字符分隔线之后的patch commentary出现。原提交消息、日志里的Notes区、补丁中的评注，因而是理解同一补充资料时需要区分的三个文字位置，不宜把补丁评注所在位置反写成原提交消息已经改变。

附注内容本身在原则上是普通Git blob，手册接受不同格式，而非只认可一种固定文本模板。它同时提醒，非文本附注放到日志里显示未必有意义。这把“能够保存”与“适合这样显示”分开：对象可以容纳某种内容，并不表示日志的文字呈现已经适合解释它。本篇只依据官方手册的对象与显示语义，未执行Git或检验真实仓库；页面更新记录不作为首次发布日期。

资料：[1] https://git-scm.com/docs/git-notes

信息来源

本文基于上述公开资料整理，未使用来源页面的图片、视频或嵌入媒体。