使用基于功能分支的 rebase 提交消息修改，然后合并到 master答案

【问题标题】：Commit message amend using rebasing on feature branch and then merging into master使用基于功能分支的 rebase 提交消息修改，然后合并到 master
【发布时间】：2020-10-26 14:43:50
【问题描述】：

我有一个旧提交，它是在一个旧分支上进行的，比如“old_branch_1”。此提交通过拉取请求合并到我的“主”分支中。现在我需要修改该提交的消息。所以我按照以下步骤操作：

从“master”创建了一个新分支，比如“new_branch_1”。
是否结帐 new_branch_1。
使用 git rebase -i HEAD~50 然后修改了所需的提交信息。
一次，rebase 完成。我在远程之前提交了 100 次，在远程之后提交了大约 120 次。
git pull（并解决了冲突）。现在我提前了 200 次提交。
做了 git push。
现在，我向我的 master 分支提出了 PR。

我不确定的是，无论是 PR 合并后，它会用新消息替换旧提交还是将这个新提交添加到主分支历史记录的顶部。

我真的需要从历史中删除旧的提交消息。因为在将我的代码合并到生产分支时，旧消息会导致问题。

【问题讨论】：

你和twitter.com/henryhoffman/status/694184106440200192的声音很接近。当您更改提交消息时，您会创建一个新提交，因此会创建所有后续提交的新版本。这不会改变任何现有的提交，它只会添加更多的提交，让你的历史更难理解。
@jonrsharpe 是的，我同意你的看法。但是，还是想知道。一定有办法实现这一点？
不会，如下所述，如果没有可能导致合作者出现问题的强制推送。也许您应该在其他地方寻找修复（例如找出为什么仅凭消息就足以导致可能正常工作的代码无法合并）。

标签： git github commit rebase pull-request

【解决方案1】：

TL;DR：摆脱评论的唯一方法是变基然后强制推送。如果您所在的团队目前正在开发各种主题分支，这很可能会引起很多麻烦。

变基会更改每个受影响提交的提交 ID。在你的 rebase 之后，你有与 master 在你分支时相同数量的提交，但最近的 50 个有不同的提交 ID。那时你应该提前 50 次提交，落后 master 50 次。不确定你是如何提前完成 100 次提交的。如果在您结帐和完成 rebase 之间将其他代码合并到 master 中，则可能会发生额外的“提交延迟”。

当您将 master 合并回您的分支时，您带回了所有 50 个您的 rebase 修改的提交，包括提交消息。您的 PR 不会覆盖现有远程中的任何内容，而只会再添加 50 个与您的远程中的相应提交相同的提交，除了您的一个新提交具有不同的评论消息。

【讨论】：

嘿，很抱歉问题中的数字。我不记得确切的数字，但我确信在我签出和变基时没有提交其他代码。让我们假设，我比远程分支领先 50 和落后 50。现在，此时，如果我强制推送到远程，它会删除旧的提交吗？而且，请注意，我是强制推入远程功能分支而不是主控。稍后我还需要从这个远程功能分支向远程 master 提出 PR。
您需要强制推送到您想要覆盖其提交的分支。如果有任何系统允许这样的事情通过 PR 发生，我会感到惊讶。