在完成合并和解决冲突之后，是否有一种“简单”的方法来接受命令行中默认生成的提交消息？我们的一个开发人员将解决所有冲突，然后执行git commit -m"Merge Commit"，替换列出所有冲突文件的生成的提交消息。我想有一个不同的标志，只会采取当前文件没有修改。我知道有一个-F或--file=选项，但这需要始终知道文件名。
git commit -m"Merge Commit"
-F
--file=
5gfr0r5j1#
根据the docs，我只是尝试了这个简单的命令，它对我很有效：
git commit --no-edit
然后，运行git log以确认已使用默认消息。
git log
1hdlvixo2#
默认情况下，当合并失败时，要使用的提交消息会保存在git文件夹中的一个文件中，通常是.git/MERGE_MSG。冲突解决后，运行git commit将把保存的消息提供给默认编辑器。如果消息本身没有被拾取，则可以使用--file选项将其馈送到git命令，该命令从文件中读取提交消息：
.git/MERGE_MSG
git commit
--file
git commit --file .git/MERGE_MSG
qlvxas9a3#
只需将编辑器设置为不执行任何操作的命令：
GIT_EDITOR=true git commit
7rfyedvj4#
显然，这里的“正确”答案是让您的开发人员在生成合并提交时遵循正确的实践。请注意，您想要的行为过去是默认的，直到最近git才开始要求合并的提交消息是“人工生成的”。这是有原因的，而不是为了让开发人员用一条毫无意义的消息来短路这个过程。也许开发人员在他/她应该重新定基的时候生成了合并提交？也就是说，合并提交是git fmt-merge-msg的输出，您必须向其提供合并提交的父提交。
git fmt-merge-msg
yfwxisqw5#
前面提到的git commit --file .git/MERGE_MSG很好，但它忽略了几点：
.git
并且可选地：
MERGE_MSG
前两个点可以与git rev-parse一起使用：
git rev-parse
git commit -F "$(git rev-parse --git-dir)/MERGE_MSG"
或者，使用Git别名：
commit-merge = !cat $(git rev-parse --git-dir)/MERGE_MSG | git commit -F -
这在“普通”仓库和子模块中都有效。如果#标记的冲突标记应该被丢弃，为了简单起见，可以只取合并消息的第一行：
#
git commit -m $(head -1 $(git rev-parse --git-dir)/MERGE_MSG)
或者另一个别名：
commit-merge = !head -1 $(git rev-parse --git-dir)/MERGE_MSG | git commit -F -
我不得不在别名中使用-F键，因为我不能让Git发出引号，以便在生成的命令中使用bash进行处理（否则git commit将在合并期间抱怨部分提交）。两天前的Git 2.12.0版本released引入了git merge --continue来进行合并提交，在合并过程中发生冲突时会停止提交。它对于子模块也能正常工作，但不接受--no-edit，至少目前是这样，因此建议编辑器在结束合并之前更改提交消息。
git merge --continue
--no-edit
yhuiod9q6#
您可以使用默认的**“git commit”，不带消息。这将触发控制台中的Vim编辑器。Vim中将显示默认消息，只需使用命令"：wq”**应用合并并退出VIM即可。演练以下步骤：
git commit (hit enter) :wq (to exit and apply merge in VIM editor)
hec6srdp7#
$git commit --amend --no-edit
merge conflict
feature branch
rsaldnfx8#
如果你真的想强制执行这个规则，那么可能有一种方法可以使用git hooks强制执行。每次有合并冲突时，“combined diff”将显示哪些文件发生了冲突：git diff HEAD HEAD^1 HEAD^2 --name-only。我不知道从技术上讲，合并后的diff是否可以显示比冲突文件更多的文件。但是，假设它像我们想要的那样工作（这是一个假设），那么你可以有一个git commit-msg钩子来检查用户输入的消息 * 并Assert1.这是合并提交吗？1.如果是，合并后的diff是否显示文件？1.如果是，字符串“Conflicts：“后面跟的是那些文件名吗？如果这些条件都失败了，那么让脚本打印出来，以显示错误的解释，然后返回非零值以中止提交。您可以让开发人员安装这个提交钩子，或者您也可以将其安装在服务器上以确保强制执行。
git diff HEAD HEAD^1 HEAD^2 --name-only
commit-msg
8条答案
按热度按时间5gfr0r5j1#
根据the docs，我只是尝试了这个简单的命令，它对我很有效：
然后，运行
git log以确认已使用默认消息。1hdlvixo2#
默认情况下，当合并失败时，要使用的提交消息会保存在git文件夹中的一个文件中，通常是
.git/MERGE_MSG。冲突解决后，运行git commit将把保存的消息提供给默认编辑器。如果消息本身没有被拾取，则可以使用
--file选项将其馈送到git命令，该命令从文件中读取提交消息：qlvxas9a3#
只需将编辑器设置为不执行任何操作的命令：
7rfyedvj4#
显然，这里的“正确”答案是让您的开发人员在生成合并提交时遵循正确的实践。请注意，您想要的行为过去是默认的，直到最近git才开始要求合并的提交消息是“人工生成的”。这是有原因的，而不是为了让开发人员用一条毫无意义的消息来短路这个过程。
也许开发人员在他/她应该重新定基的时候生成了合并提交？
也就是说，合并提交是
git fmt-merge-msg的输出，您必须向其提供合并提交的父提交。yfwxisqw5#
前面提到的
git commit --file .git/MERGE_MSG很好，但它忽略了几点：.git目录，只有一个.git文件。并且可选地：
MERGE_MSG包含一些有关冲突文件的信息。前两个点可以与
git rev-parse一起使用：或者，使用Git别名：
这在“普通”仓库和子模块中都有效。如果
#标记的冲突标记应该被丢弃，为了简单起见，可以只取合并消息的第一行：或者另一个别名：
我不得不在别名中使用
-F键，因为我不能让Git发出引号，以便在生成的命令中使用bash进行处理（否则git commit将在合并期间抱怨部分提交）。两天前的Git 2.12.0版本released引入了
git merge --continue来进行合并提交，在合并过程中发生冲突时会停止提交。它对于子模块也能正常工作，但不接受--no-edit，至少目前是这样，因此建议编辑器在结束合并之前更改提交消息。yhuiod9q6#
您可以使用默认的**“git commit”，不带消息。这将触发控制台中的Vim编辑器。Vim中将显示默认消息，只需使用命令"：wq”**应用合并并退出VIM即可。
演练以下步骤：
hec6srdp7#
merge conflict并希望获取先前提交的消息并在feature branch中应用主代码以避免冲突时，这将很有帮助。rsaldnfx8#
如果你真的想强制执行这个规则，那么可能有一种方法可以使用git hooks强制执行。
每次有合并冲突时，“combined diff”将显示哪些文件发生了冲突：
git diff HEAD HEAD^1 HEAD^2 --name-only。我不知道从技术上讲，合并后的diff是否可以显示比冲突文件更多的文件。但是，假设它像我们想要的那样工作（这是一个假设），那么你可以有一个git
commit-msg钩子来检查用户输入的消息 * 并Assert1.这是合并提交吗？
1.如果是，合并后的diff是否显示文件？
1.如果是，字符串“Conflicts：“后面跟的是那些文件名吗？
如果这些条件都失败了，那么让脚本打印出来，以显示错误的解释，然后返回非零值以中止提交。您可以让开发人员安装这个提交钩子，或者您也可以将其安装在服务器上以确保强制执行。