Git commit -cleanup=剪刀应该被使用。它在2014.05.21被添加到Git v2.0.0中

从git提交——帮助

--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.

！ 是对历史的扩展所以才没用。

历史扩展是通过历史扩展字符的出现来介绍的，这就是!默认情况下。

你可以使用$和单引号(转义Bash单引号字符串中的单引号):

$ git commit -m $'#228 update to a new version! margin of error is 33% | 33^*0.22;'
# commit message: #228 update to a new version! margin of error is 33% | 33^*0.22;

$ git commit -m $'docs!: new API reference for GPS horse navigation'
# commit message: docs!: new API reference for GPS horse navigation

如果没有$和' but '加上":

$ git commit -m "docs!: new API reference for GPS horse navigation"
bash:  : unrecognized history modifier

如果与"和escape \一起使用(\仍然会在那里，或者我做错了什么):

$ git commit -m "docs\!: new API reference for GPS horse navigation"
# commit message: docs\!: new API reference for GPS horse navigation

我所有的提交都以#issueNumber开始，所以我把这个样板文件放在我的vim .git/hooks/commit-msg中:

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

假设我们有分支#15，我们让commit message添加新的很棒的功能。使用这种方法，最终提交消息将#15添加新的很棒的功能。

只需在# char之前使用空格字符开始提交消息即可。

然后git停止将该行视为注释，github可以毫无问题地使用散列票号。

Vim的默认语法高亮显示甚至通过将注释的颜色更改为内容的颜色来建议该功能。

使用不同的票号前缀。或者在票号前加上一个词，比如“Bug #42”。或在行前加上一个空格字符;如果你想移除空白，你可以添加一个commit-hook。

我个人不希望这种提交消息操作由钩子完成，因为当它在你不想要的时候触发时，它会非常令人恼火。最简单的解决办法可能是重新思考这个问题。

请注意，从git1.8.2(2013年2月)开始，您可以在提交消息中的注释行中使用不同于'#'的字符。

这允许您使用“#”作为bug编号引用。

Git在要求用户在编辑器中编辑消息时给出的各种“提示”行默认情况下会用“#”注释掉。 commentchar配置变量可以用来自定义这个“#”为不同的字符。

理论上，你可以放一个core.commentChar字(多个字符)，但是git 2.0.x/2.1将更加严格(2014年第三季度)。

参见commit 50b54fd by nguyfrecn Thái ngibmc Duy (pclouds):

config:严格的core.commentChar

我们不支持注释字符串(至少现在还不支持)。多字节字符编码也可能被误解。 带有两个逗号的测试被更新，因为它违反了这一点。它与在eff80a9中引入core.commentChar的补丁一起添加(允许自定义“comment char”- 2013-01-16)。我不清楚为什么这种行为是需要的。

git 2.0.x/2.1(2014年Q3)将添加一个core.commentChar的自动选择: 参见commit 84c9dc2

当core.commentChar为"auto"时，评论字符默认以'#'开头，但如果它已经在准备好的消息中，请在一个小子集中找到另一个字符。这应该会停止意外，因为git会意外地删除一些行。 注意，git还不够聪明，无法在自定义模板中将'#'识别为注释字符，并在最终的注释字符不同时将其转换。 它认为自定义模板中的“#”行是提交消息的一部分。所以不要在自定义模板中使用这个。

"auto"的候选字符列表有:

# ; @ ! $ % ^ & | :

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

参见Tom Wright的“生成散列-在Git提交消息中使用#s”

The Stackoverflow answer I linked to above also mentions a feature in Git that will choose a comment character automatically, based on the characters you use in commit messages. git config --global core.commentChar auto Sounds great right? Unfortunately, it only changes the comment character based on commits made after you turn it on; it doesn’t use your commit history to inform the choice. To my mind, this is a great feature hobbled by poor execution. It seems like a feature that would be effective only if it were on by default: One group of people will simply avoid using hashes in commits because they are familiar with the consequences. Others (like us) will only realise they need to change the comment character when they need to do a rebase. It doesn’t make sense in this situation to add a new commit just to trigger the desired behaviour. A third group of people will consciously accept early on that they need to change the default comment character and will simply choose an alternative. In other words, having this feature available as a non-default option helps virtually no-one. Since having it on by default would do nothing to harm any users, and would remove a pain point for some users, I can’t work out why this isn’t the case. Git isn’t famed for its usability, but to have a fix available and not to turn it on seems gratuitously user-hostile.