**tl;dr：**通常你不应该有一个新的提交来解决冲突，而是应该有其他的提交来解决冲突。因此，你不需要一个特定的标题来解决冲突。
免责声明：我以前从未真正使用过常规提交，但是我读过几次规范。
详细示例：

假设你有一个分支feat/add-new-thingy，有两个新的提交，想象一下当你运行git log --oneline时，你会看到：

222 fix: prevent stack overflow (HEAD -> feat/add-new-thingy, origin/feat/add-new-thingy)
111 feat: add new thingy
000 ... (main)

假设你尝试使用Pull Request将分支合并到GitHub上的main，但是远程版本的main比你开始的版本要早，并且你当前有冲突。在获取并运行git log origin/main --oneline后，你会看到如下所示：

bbb feat: add more ducks to the pond (origin/main)
aaa fix: increase maximum stack size
000 ... (main)

在你的分支上，你添加了一个新特性，但也修复了一个堆栈溢出错误。看起来其他人也修复了堆栈溢出错误，但可能是用了与你不同的方法。这种可能性很大（但不一定）产生冲突的原因。为了解决冲突，您通常会将merge中最新版本的origin/main添加到您的分支中，或者你可以把你的分支rebase到最新的origin/main上，让我们先看看merge会发生什么：

git fetch # probably up to date since we fetched 1 minute ago, but it can't hurt
git switch feat/add-new-thingy # probably already checked out
git merge origin/main # conflicts

如果没有冲突，你现在只会得到一个带有“Merge remote-tracking分支'origin/main' into feat/add-new-thingy”消息的合并提交。注意，如果你愿意，你可以修改合并提交消息，但即使你这样做了也没有必要为合并提交使用约定提交类型，因为每个相关的提交都已经指定了它们的类型。
如果你 * 确实 * 有冲突，那么你就解决它们并提交合并，通常你不需要修改合并提交消息，相比之下，没有冲突的合并提交消息会是什么样子。**因此，即使有冲突，你的合并提交消息也只是一个普通的合并提交消息。**在合并了你解决的冲突之后，你只需推送：

git push # Now your PR can be completed.

如果选择通过重定基准来解决冲突，而不是合并，例如：

git fetch # probably up to date since we fetched 1 minute ago, but it can't hurt
git rebase origin/main feat/add-new-thingy # conflicts

为了解决冲突，您将在提交每个有冲突的提交之前被停止，在本例中，最有可能是在2次提交中的第2次。解决冲突后，您将提交自己，或git rebase --continue以重用现有的提交消息，以及您的第二次提交，“修复：将以解决冲突的新方式写入“防止堆栈溢出”。使用变基，没有额外的提交。