Git-notes

使用git notes，你可以在提交中添加“注解”。你也可以将它们添加到其他Git对象中，但我们只关注提交，因为这是问题的关键所在。
注解是一个Git对象，原则上可以是“whatever”（任意数据）。但我们将集中在一些简单的和文本的东西为我们的目的。

示例：审查ID

这个问题提到了审查id，所以让我们用一些方法来表示这样的东西。我不知道什么审查id真的看起来像，但希望以下是明智的：

Review-id: 42

所以这实际上是一个键值对。让我们将上面的字符串添加到当前提交：

git notes add -m "Review-id: 42"

如果你运行git log，注解将显示在行内：（†1）

Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes:
    Review-id: 42

另一个示例

当然，您可以在这个注解中添加更多的“子注解”（我们将坚持使用简单的key: value语法，每行一个值）。例如，如果你在三个月后发现提交消息有错误，只需在注解中添加更正即可：

git notes append -m "Errata: It was actually feature y."

git log：

Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes:
    Review-id: 42

    Errata: It was actually feature y.

我们使用git notes append，以便轻松地将这些额外的数据添加到注解中。您也可以使用git notes edit来直接编辑文件。
当然，由于Git note只是一个可变文件，因此可能会遇到合并冲突。为了降低这种可能性，您可以：
1.坚持使用像上面这样的简单数据（每行一个键值）。
1.使用特殊的合并策略;参见man git-notes，“Notes合并策略”一节。

可见性

OP问：
〉我可以使某些标签不可见吗？
默认情况下，git log只显示一个音符，即.git/refs/notes/commits。commits只是命名空间中的一个注解。也许你希望 issues 在它们自己的命名空间中：

git notes --ref=issues add -m "Fixes: #32"

由于这是存储在.git/refs/notes/issues中，而不是存储在.git/refs/notes/commits中，因此“修复：运行git log时不会显示#32”。因此，默认情况下，您实际上已使此类注解不可见。
如果你想让它显示出来，将--notes=issues传递给git log：

$ git log --notes=issues
Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes (issues):
    Fixes: #32

但是现在.git/refs/notes/commits被隐藏了。其中一个也可以很容易地被包括在内：

$ git log --notes=issues --notes=commits
Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:25 2016 +0100

    Implement feature x

Notes (issues):
    Fixes: #32

Notes:
    Review-id: 42

    Errata: It was actually feature y.

有变量来配置默认显示哪些笔记;参见man git-config。

相对于提交消息的优势

元数据当然可以直接记录在提交消息中。（†2）但是提交消息是不可变的，因此更改它们实际上意味着进行一次全新的提交，这会带来所有的后果。另一方面，Git-notes是可变的，所以你总是可以修改它们。当然，对注解的每个修改都是版本控制的。在我们的例子中，对于.git/refs/notes/commits：

$ git log refs/notes/commits
Author: Victor Version Control <vvc@vcs.org>
commit 9f0697c6bbbc6a97ecce9834d4c9afa0d668bcad
Date:   Tue Nov 8 21:13:52 2016 +0100

    Notes added by 'git notes append'

commit b60997e49444732ed2defc8a6ca88e9e21001a1d
Author: Victor Version Control <vvc@vcs.org>
Date:   Tue Nov 8 21:10:38 2016 +0100

    Notes added by 'git notes add'

分享笔记

默认情况下不会共享您的笔记;你必须明确地这样做。与其他参考相比，分享笔记并不是很方便用户。我们必须使用 refspec 语法：

git push refs/notes/*

上面的操作会将您的所有笔记推送到遥控器。
看起来取笔记更复杂一点;如果指定refspec的两侧，则可以执行此操作：

git fetch origin refs/notes/*:refs/notes/*

所以这绝对不方便。如果你打算经常使用Git-notes，你可能需要设置你的gitconfig来总是获取笔记：

[remote "origin"]
    …
    fetch = +refs/notes/*:refs/notes/*

重写时结转注解

Git有一个不方便的默认设置，即当提交被重写时，注解不会被结转。因此，如果你对一系列的提交进行了改基，这些注解将不会延续到新的提交中。
变量notes.rewrite.<command>默认设置为true，因此可以假设音符 * 被 * 结转。但问题是，变量notes.rewriteRef，它决定了 * 哪些 * 音符将被结转，没有deaf值。要将此值设置为匹配所有注解，请执行以下操作：

git config --global notes.rewriteRef "refs/notes/*"

现在，在执行git rebase等重写操作时，将保留所有注解。

通过邮件补丁结转笔记

如果你使用git format-patch来格式化你的更改以电子邮件的形式发送，并且你有一些元数据存储为Git笔记，你可以将--notes选项传递给git format-patch，以便将笔记附加到电子邮件草稿中。
但请记住，这个开关看起来并不像是用来将笔记作为元数据共享的;它们只是被添加在自由形式信息部分中的提交消息和补丁适当部分之间。所以（就像larsks在评论中提到的那样）如果你真的想把笔记作为适当的元数据共享，你可能只想把数据合并到提交消息中。
† 1：“这是git log [...]的默认值，当命令行上没有给出--pretty、--format或--oneline选项时。”-man git-log，git version 2.10.2
† 2：一种用于提交消息中的元数据的实践/约定，例如Git和Linux内核是在提交消息的“trailer”中添加键值对，即在底部。参见Linus Torvalds的this commit：

mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
 This is an ancient bug that was actually attempted to be fixed once
 (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
 get_user_pages() race for write access") but that was then undone due to
 problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

 In the meantime, the s390 situation has long been fixed, and we can now
 fix it by checking the pte_dirty() bit properly (and do it better).  The
 s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
 software dirty bits") which made it into v3.9.  Earlier kernels will
 have to look at the page state itself.

 Also, the VM has become more scalable, and what used a purely
 theoretical race back then has become easier to trigger.

 To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
 we already did a COW" rather than play racy games with FOLL_WRITE that
 is very fundamental, and then use the pte dirty flag to validate that
 the FOLL_COW flag is still valid.

 Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
 Acked-by: Hugh Dickins <hughd@google.com>
 Reviewed-by: Michal Hocko <mhocko@suse.com>
 Cc: Andy Lutomirski <luto@kernel.org>
 Cc: Kees Cook <keescook@chromium.org>
 Cc: Oleg Nesterov <oleg@redhat.com>
 Cc: Willy Tarreau <w@1wt.eu>
 Cc: Nick Piggin <npiggin@gmail.com>
 Cc: Greg Thelen <gthelen@google.com>
 Cc: stable@vger.kernel.org
 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

参见：

• man git-interpret-trailers
• This Kernel Wiki page列出了各种项目中使用的各种尾部行（通常是键值对）。

这正是git notes的作用。