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

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

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

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

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

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

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

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

这里的答案很好，也很详细，但是对于像我这样的git新手来说，定制git配置选项并不是那么明显。下面是一个从#改为;注释字符:

git config core.commentChar ";"

这就是你所需要做的。

请注意，从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.

如果你正在做一个交互式的rebase，那么当你保存你的提交消息时，里面什么都没有(因为在开始的#已经使它成为一个注释，因此它被忽略了)，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