#
(井号、数字符号、八角符号、磅号)开头的行视为注释行。这在与票务跟踪系统一起工作并尝试在行首写入票号时非常令人恼火,例如:#123 salt hashed passwords
Git会简单地从提交消息中删除该行。有没有办法转义哈希符号?我尝试了\和!,但都不起作用。空格在#之前被保留,所以这也不是解决问题的方法。
#
(井号、数字符号、八角符号、磅号)开头的行视为注释行。这在与票务跟踪系统一起工作并尝试在行首写入票号时非常令人恼火,例如:#123 salt hashed passwords
这种行为是 git commit
默认的“清理”行为之一。如果要保留以 #
开头的行,可以使用替代的清理模式。
例如:
git commit --cleanup=whitespace
如果你这样做,你必须小心地删除所有你不想在提交中出现的 #
行。
commit.template
Git配置变量控制。 - CB Baileygit commit --amend --cleanup=whitespace
。 - James Andres--cleanup=scissors
和[commit] cleanup = scissors
。这两个选项可以做到--cleanup=whitespace
的所有功能,并自动剥离每个提交消息后缀中的注释变更。 - Cecil Curry#
'的字符进行注释。#
'来引用您的错误编号。#
'注释掉了。core.commentChar
配置变量将此'#
'自定义为其他字符。
core.commentChar
单词(多个字符),但git 2.0.x / 2.1将更加严格(Q3 2014)。pclouds
):
core.commentChar
in eff80a9(允许自定义“注释字符”- 2013-01-16)的补丁中添加的。我不清楚为什么需要这种行为。
git 2.0.x/2.1(2014年第三季度)将为core.commentChar
添加自动选择功能:
请参见提交 84c9dc2
当
core.commentChar
为“auto
”时,注释字符以默认情况下的“#”开头,但如果它已经在准备好的消息中,则在一个小的子集中查找另一个字符。这应该可以防止因为git意外地剥离了一些行而导致的惊喜。请注意,git不足够聪明,无法识别自定义模板中的“#”作为注释字符,并在最终注释字符不同时进行转换。
它认为自定义模板中的“#”行是提交消息的一部分。因此,请勿在自定义模板中使用此功能。
“auto”候选字符列表如下:
# ; @ ! $ % ^ & | :
git commit -m '#1 fixed issue'
这样的命令将自动将 commentChar 切换为 ';
', 因为提交消息中使用了 '#
'。
查看 "在Git提交信息中使用#s
",作者为Tom Wright
注意:Git 2.41(2023年第2季度)增加了:
请参见提交 d3b3419(2023年3月27日),作者为Kristoffer Haugsbakk(LemmingAvalanche
)。
(由Junio C Hamano -- gitster
--合并于提交 5c93cfd,2023年3月31日)
提交 50b54fd(“
config
: 告诉用户我们期望一个ASCII字符签名者:Kristoffer Haugsbakk
config
: 对core.commentChar
进行严格检查”,2014-05-17, Git v2.1.0-rc0 -- merge列在batch #2)记录了“多字节字符编码也可能被错误地解释”,实际上,多字节代码点(非ASCII)不被接受为有效的core.commentChar
。core.commentChar should only be one ASCII character
^^^^^
$ git config --global core.commentchar ';'
。该命令会将Git的注释符号设置为分号(;)。 - davetapleygit config --global core.commentChar auto
。 - aross#
改为 ;
:git config core.commentChar ";"
git commit
打开配置的编辑器来编辑提交消息时,这也会更改Git添加到提交消息中的默认注释文本! - Michahellgit -c core.commentChar="|" commit --amend
(将 |
替换为您想要的任何字符)。 - yurisich-m
:git commit -m "#123 fixed"
git commit -m "#123 fixed" -m "Long commit"
,它也适用于 --amend。 - Ulrik McArdle#
将其变成了注释,因此被忽略了)时,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
应该使用 git commit --cleanup=scissors
。它被添加到Git v2.0.0 中,在2014年5月21日。
来自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.
commit.cleanup = whitespace
并手动删除 # …
注释更好,正如 @CharlesBailey 已经建议的那样。scissors
模式只是额外清理了 git
format-patch
/mailinfo
/am
使用的剪刀语法;它在添加提交消息注释时不会使用 …-- >8 --…
语法。 - Slipp D. Thompson#...
注释”。git commit --help
中。你使用的是哪个版本的git
?@SlippD.Thompsonwhitespace
模式提供了以下功能:1. 去除前导和尾随空行,2. 去除尾随空格,3. 折叠连续的空行。scissors
模式提供了以下功能:1. 去除前导和尾随空行,2. 去除尾随空格,3. 折叠连续的空行,4. 从(包括)行 # -…- >8 -…-
开始的所有内容。然而,只有在使用 git-format-patch
/mailinfo
/am
时才会插入剪刀线(# -…- >8 -…-
)。因此,在正常的 git-commit
/merge
/rebase
/cherry-pick
工作流中,scissors
剥离模式与whitespace
模式相比没有任何优势。v2.11.0 - Slipp D. Thompsongit commit --cleanup=scissors
确实会在git status
信息之前添加# ------------------------ >8 ------------------------
行。就像下面这样:# ------------------------ >8 ------------------------
# 不要触碰上面的行。
# 下面的所有内容都将被删除。
# 在主分支上
#
# 初始提交
#
# 要提交的更改:
# 新文件: .gitignore
- Sungam# ------------------------ >8 ------------------------
;但是,在# Conflicts:…
文本之后插入剪刀线。我在.gitconfig
中设置了commit.status = false
,因此我没有看到任何状态文本,只有冲突文本。我改变立场,点赞。 - Slipp D. Thompson我所有的提交都以#issueNumber
开头,因此我将这个模板放在了vim .git/hooks/commit-msg
中:
NAME=$(git branch | grep '*' | sed 's/* //')
echo "$NAME"' '$(cat "$1") > "$1"
#15
,并且我们进行了提交信息add new awesome feature
。使用这种方法,最终的提交信息将是#15 add new awesome feature
。使用不同的前缀来表示票号。或者在票号前添加一个单词,比如“Bug #42”。或者在行首添加一个空格字符;如果你想要删除这个空白字符,可以为此添加一个提交钩子。
我个人不太希望通过钩子进行这种提交消息的操作,因为当你不想触发它时,它可能会非常烦人。最简单的解决方案可能是重新思考这个问题。
#xxx
的内容将链接到问题。它不必在提交的开头。也许这是在过去五年中发生了变化的事情? - Guildenstern!
是历史展开这就是为什么它没有工作。
历史扩展是通过历史扩展字符的出现引入的,默认情况下是
!
。
您可以使用带单个 '
引号的 $
(在 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
如果在不使用 $
和 '
的情况下,使用 "
:
$ git commit -m "docs!: new API reference for GPS horse navigation"
bash: : unrecognized history modifier
如果与"
一起使用并转义\
(\
仍将存在,或者我做错了什么):
$ git commit -m "docs\!: new API reference for GPS horse navigation"
# commit message: docs\!: new API reference for GPS horse navigation
#
作为第一个字符的问题?除了注释之外,这个回答甚至没有包含#
。 - knittl$
和'
)意味着转义任何字符,包括#
。我已经更新了答案。 - Dmitriy Zubgit commit -m '...'
。在过去的12年中,这已经成为所有答案的一部分。我没有看到这个答案添加了哪些新信息,除了解释与问题无关的shell引用规则。在您的任何命令中都不需要 $
(并且仅适用于bash)。 - knittl
git config core.commentchar
允许配置注释字符。请参见下面的我的答案。 - VonCgit commit --cleanup=scissors
更加灵活。详细信息请参见我的回答。 - Sungam