使用井号（＃）启动git commit消息

283

#提交时，Git 将以开头的行视为注释行。当使用票证跟踪系统并尝试在行首写票证号时，这非常烦人。

#123 salt hashed passwords

git只会从提交消息中删除该行。有什么办法可以逃脱哈希？我尝试了\和!，但没有任何效果。保留以前#的空格，因此它们也不是解决该问题的有效方法。

— 针织
source

8

@AlexBudovski，因为简洁有其价值。

— 哈维2014年

8

自git 1.8.2（2013年2月）以来，git config core.commentchar允许配置该注释字符。请在下面

— VonC 2014年

3

由于Git v2.0.0（2014.05.21）git commit --cleanup=scissors将更加灵活。请参阅我的答案中的

— Sungam '16

4

我必须说，让GitHub人们决定使用哈希标记问题编号时，我没有想到这个问题，我感到很惊讶！

— Michael Scheper

1

@Michael公平地说，Mantis，Trac，Redmine和其他人可能已经使用了此约定。我想GitHub只是决定遵循它，而不是重新发明轮子。参见stackoverflow.com/questions/40495/…–

— kelvin

235

此行为是git commit的默认“清理”行为的一部分。如果要使行开头，#可以使用其他清除模式。

例如

git commit --cleanup=whitespace

如果这样做，则必须小心删除所有#不想出现在提交中的行。

— 世邦魏理仕
source

下一个问题是：在哪里可以编辑git引入的提交消息注释（默认情况下以＃开头）？

— 亚历克斯（Alex）

2

@Alex：它由commit.templategit配置变量控制。

— CB Bailey

23

这对于修改现有提交也很有用。例如：git commit --amend --cleanup=whitespace

— 詹姆斯·安德烈斯

@CharlesBailey：我期待使用git commit -t / dev / null摆脱预定义的文本，但它仍显示

— Alex

由于您可以拥有“＃123提交消息”的提交消息以及诸如GitHub for Mac和SourceTree之类的客户端中的注释，我想这些客户端在做什么？

— Phil Ostler 2014年

134

请注意，自git1.8.2（2013年2月）以来，您可以#在提交消息中的注释行中使用与'字符不同的字符。

这使您可以使用“ #”作为错误编号参考。

Git要求用户在编辑器中编辑消息时给出的各种“提示”行#默认情况下用'注释掉。

所述core.commentChar配置变量可用于这种“自定义#”到一个不同的角色。

从理论上讲，您可以输入一个core.commentChar单词（多个字符），但是git 2.0.x / 2.1会更严格（2014年第三季度）。

见提交50b54fd由阮泰玉维战（pclouds）：

config：对core.commentChar严格

我们不支持注释字符串（至少目前还不支持）。而且多字节字符编码也可能会被误解。

具有两个逗号的测试将被更新，因为它违反了此要求。它与eff80a9中引入core.commentChar的修补程序一起添加（允许自定义“注释字符” -2013-01-16）。我不清楚为什么要这种行为。

git 2.0.x / 2.1（Q3 2014）将为以下项添加自动选择core.commentChar：
参见commit 84c9dc2

当core.commentChar为“ auto”时，#默认情况下，注释字符以' ' 开头，但默认情况下，如果已在准备好的消息中，请在一个小的子集中找到另一个字符。这应该停止意外，因为git意外剥离了一些行。

请注意，git不够聪明，无法将' #' 识别为自定义模板中的注释字符，如果最终注释字符不同，则将其转换。
它认为自定义模板中的“＃”行是提交消息的一部分。因此，请勿将其与自定义模板一起使用。

“自动”的候选字符列表为：

# ; @ ! $ % ^ & | :

这意味着像这样的命令git commit -m '#1 fixed issue'将自动将commentChar切换为“ ;”，因为#在提交消息中使用了“ ”。

— 冯
source

1

后此修复程序的语法HL，请参阅此相关的问题：stackoverflow.com/questions/16164624/...

— 阿洛伊斯Mahdal

@Guten是的，我已经改写了答案以反映这一点。

— VonC 2014年

1

@newbyca和git的哪个版本在交互式rebase期间不支持？

— VonC

2

因此，您可以进行设置，例如：$ git config --global core.commentchar ';'

— davetapley14年

6

我喜欢这个答案。Oneliner新建议的解决方案：git config --global core.commentChar auto

— aross

81

这里的答案很好而且很详细，但是对于像我这样的git noob来说，自定义git config选项并不是很明显。这里是从变化的示例#，以;用于注释字符：

git config core.commentChar ";"

这就是您需要做的。

— 马修·那不勒斯
source

3

当一个人用来打开已配置的编辑器来编辑提交消息时，这也会更改git添加到提交消息中的默认注释文本git commit！

— Michael Trouw

1

对于一次性修复程序，请使用以下命令：（git -c core.commentChar="|" commit --amend替换|为所需的任何内容）。

— Droogans

62

您可以使用命令行选项-m：

git commit -m "#123 fixed"

— 奥利维尔·威尔第（Olivier Verdier）
source

35

但这是一个可怕的提交信息。确保包括错误是什么以及如何修复

— 好人

3

只要存在多个错误，提交消息就可以

— Trident D'Gao

6

如果错误跟踪系统突然损坏并且您没有备份，那就不会了！:)

— Caveman_dick 2015年

38

如果您正在进行交互式基准，那么当您保存提交消息而没有任何内容时（因为#开始时已将其添加为注释，因此被忽略了），git将向您显示操作：

Aborting commit due to empty commit message.
Could not amend commit after successfully picking 5e9159d9ce3a5c3c87a4fb7932fda4e53c7891db... 123 salt hashed passwords
This is most likely due to an empty commit message, or the pre-commit hook
failed. If the pre-commit hook failed, you may need to resolve the issue before
you are able to reword the commit.
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

因此，只需修改以下信息：

git commit --amend -m "#123 salt hashed passwords"

并继续变基：

git rebase --continue

— 奥因·威廉姆斯（Owain Williams）
source

对于已经推送提交但想要更改消息的人来说，这是正确的

— Hoang Trinh，

如果您使用编辑器输入消息，并且开头有一个哈希，则它也适用于新提交。

— Owain Williams

29

git commit --cleanup=scissors应该使用。它已于2014.05.21 添加到Git v2.0.0

从 git commit --help

--cleanup=<mode>
  scissors
    Same as whitespace, except that everything from (and including) the line
    "# ------------------------ >8 ------------------------" is truncated if the message
    is to be edited. "#" can be customized with core.commentChar.

— gam岩
source

我不明白这比手动使用commit.cleanup = whitespace和删除# …评论更好，就像@CharlesBailey已经建议的那样。 scissors-mode只是还清理了git format-patch/ mailinfo/ 所使用的剪刀语法am。它并没有使用…-- >8 --…添加注释，以提交信息时的语法。

— Slipp D. Thompson

1.我认为这样比较好，因为我不需要“ # ...逐个删除评论。” 2.我不确定您评论的第二部分，该scissors模式肯定在git commit --help。git您使用的是哪个版本？ @ SlippD.Thompson

— Sungam '17

?？whitespace模式可剥离1.开头和结尾的空行，2.结尾的空白，3.折叠连续的空行。scissors提供以下内容的剥离：1.前导和尾随的空行； 2.尾随空白； 3.折叠连续的空行； 4.从（包括）该行的所有内容# -…- >8 -…-。但是，# -…- >8 -…-仅在使用git-format-patch/ mailinfo/ 时才插入剪刀行（）am。因此，对于一个正常的git-commit/ merge/ rebase/ cherry-pick工作流程，scissors剥离模式提供了零收益whitespace模式。v2.11.0

— Slipp D. Thompson

@ SlippD.Thompson您正在使用什么版本的git？我使用的是2.8.3和git commit --cleanup=scissors DOES前面加上# ------------------------ >8 ------------------------前行git status信息。如下所示：`＃------------------------> 8 ------------------- -----＃请勿触摸上方的线。＃以下所有内容将被删除。的.gitignore`：＃分支主##初始提交##变更，必须承诺：＃新的文件

— Sungam

1

我相信我已经深入到此。在使用时，Git确实确实# ------------------------ >8 ------------------------在状态txt之前插入了“看起来好像您……” _之前的scissors；但是，它将在文本后插入剪刀行# Conflicts: …。我已经commit.status = false设置了.gitconfig，所以我没有看到任何状态文本，只有冲突文本。我纠正了；改变以投票。

— 斯利普·汤普森

3

请为票证编号使用其他前缀。或在票号前加一个字，例如“ Bug＃42”。或在行前添加一个空格字符；如果您希望删除该空格，则可以为此添加一个提交挂钩。

我个人不希望通过钩子来执行这种提交消息操作，因为当您不希望它触发时，它可能会很烦人。最简单的解决方案可能是重新考虑问题。

— 威廉姆特
source

1

不同的措辞只是解决该问题的方法。如果项目准则指出提交消息必须以票证ID开头，则它将不起作用。提交后的钩子非常难看。我认为我应该向git开发人员报告此“错误”

— knittl

不要打扰，那是错误的。不要要求git开发人员按照您的指南工作。您不会要求Dennis Ritchie更改C语言，因此它支持您以哈希字符开头的变量名约定，对吗？此处同样适用。如果提交消息允许注释，则这会增加对有趣事物的支持，例如在添加了diff并注释掉差异的情况下打开提交编辑器，因此您无需记住您的确切更改。保留前导空格字符有什么问题？

— 威廉·泰勒

1

在git的commit消息中支持转义字符没什么大不了的

— knittl 2010年

5

这是一个非常合理的功能要求。尤其是考虑到以下事实：如果提交消息不是以清单编号开头（以哈希开头），则AFAICT不会将提交与错误清单相关联。因此，这不仅是某人的标准，还是该工具的必需语法。让Git开发人员决定是否值得。（是的，Trac也可以解决该问题。要求Git尽其所能也没有错。）

— Luke Maurer

“尤其是考虑到Trac，AFAICT不会将提交与错误清单相关联，如果提交消息不是以清单编号开头（以哈希开头）的话。” -以我在Trac方面的有限经验，诸如#xxx在提交消息中的任何地方发生的事情都会链接到该问题。它不必在提交的开始。也许这是最近五年发生的变化？

— Guildenstern

1

我所有的提交都始于，#issueNumber所以我把这个样板放到了我的vim .git/hooks/commit-msg：

NAME=$(git branch | grep '*' | sed 's/* //') 
echo "$NAME"' '$(cat "$1") > "$1"

因此，假设我们有一个分支#15，并且制作了commit message add new awesome feature。通过这种方法，最终提交消息将为#15 add new awesome feature。

— valignatev
source