我可以向git提交添加元数据吗？或者我可以在gitk中隐藏一些标签

Question

我想将自定义元数据与a关联git commit.专门用于记录代码审查中的审阅ID,但它可以是任何内容.标签似乎是一种自然的方式,但我希望每次提交都有一个评论,我不想让gitk大量的标签混乱.是否有其他机制来添加自定义元数据？我可以让某些标签隐身吗？如果我gitk不能显示匹配某些模式或RE的标签,那可能会有效,但我没有办法做到这一点.

Answer 1

这正是git笔记的用途.

Answer 2

Git的,笔记

有了git notes你可以添加一个"注"的承诺.您也可以将它们添加到其他Git对象,但是我们只关注提交,因为这就是问题所在.

注释是Git对象,原则上可以是"任意"(任意数据).但是,为了我们的目的,我们将专注于简单和文本的东西.

示例:审核ID

这个问题提到了审核ID,所以让我们用某种方式来表示这样的事情.我不知道哪些评论ID确实如此,但希望以下是明智的:

Review-id: 42

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

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

如果你运行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

另一个例子

当然,您可以在此笔记中添加更多"子注释"(我们将坚持使用简单的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注释只是一个可变文件,因此可能会遇到合并冲突.为了减少这种可能性,您可以:

1. 坚持像上面这样的简单数据(每行一个键值).
2. 使用特殊的合并策略; 请参阅man git-notes"注释合并策略"部分.

能见度

OP问道:

>我可以让某些标签隐身吗？

默认情况下,git log只显示一个音符,即 .git/refs/notes/commits.commits只是命名空间中的一个注释.也许您希望问题出现在他们自己的命名空间中:

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

由于存储在" .git/refs/notes/issues而不是存储"中,因此 .git/refs/notes/commits运行时不会显示"修复:#32" git log.所以你默认有效地使这些笔记不可见.

如果要显示它,请传递--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.

与提交消息相比的好处

元数据当然可以直接记录在提交消息中.但是提交消息是不可变的,因此改变它们实际上意味着进行一次全新的提交,并带来所需的所有涟漪效果.另一方面,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/*

(来源:https://git-scm.com/blog/2010/08/25/notes.html)

重写笔记

Git有一个不方便的默认值,即在重写提交时不会继续注释.因此,如果您举例说明一系列提交,那么这些注释将不会转移到新的提交中.

notes.rewrite.<command>默认情况下true,该变量设置为,因此可以假设笔记已被转移.但问题在于,notes.rewriteRef确定哪些笔记将被结转的变量 没有任何缺陷.要将此值设置为与所有注释匹配,请执行以下操作:

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

现在所有笔记都将在执行重写操作时继续执行git rebase.

通过电子邮件补丁进行记录

如果您使用git format-patch格式化更改以作为电子邮件发送,并且您将一些元数据存储为Git便笺,则可以将--notes 选项传递git format-patch给电子邮件草稿以附加注释.

†"这是默认的git log[...]当没有--pretty, --format或者--oneline在命令行上给出的选项." - man git-log,Git版本2.10.2