Git：如何在 rebase 后使提交消息中的 SHA 保持最新？

Posted 2023-02-19

【中文标题】Git：如何在 rebase 后使提交消息中的 SHA 保持最新？

【英文标题】：Git: How to keep SHAs in commit messages up-to-date after rebase?

【发布时间】：2013-07-25 00:08:03

【问题描述】：

假设我在feature 分支上，创建于master。我做了一个提交

Fix XYZ

假设其 SHA 是 389b04。然后，我进行另一个提交，在其提交消息中我提到了之前的 SHA。

Fix UVW

This fix is related to the fix in 389b04.

在那之后，我做了一堆其他的提交。现在，我将feature 分支与master 同步，所以我使用git rebase master。但是，由于 rebase 更改历史记录，它会更改引用的提交 389b04 的 SHA，因此第二个提交现在引用了一个不存在的提交。

我的问题是：是否有可能在执行rebase 时自动修复提交消息中的此类 SHA？我知道这可以通过使用merge 来解决，但我想知道是否有办法使用rebase 来解决这个问题。

【问题讨论】：

我不知道有什么办法......如果你没有太多消息要更改，你可以在rebase之后过滤提交消息并手动修复它们

@knittl：是的，我可以。但是，手动方式很容易出错，因为您可能会忘记您已将 SHA 放入某些提交中。此外，定期执行rebase 会变得乏味。所以，我正在寻找一种自动方式。

绝对没有 git 内置的自动功能可以做到这一点。您可以编写一个与git filter-branch 一起使用的脚本来过滤提交消息，但这有点棘手。一般而言，当我重新定位/重写未发布的历史记录时，我只会“重新定位 -i”并将修复移动到我引入错误的位置旁边，然后合并提交，从而完全避免该问题。 :-)

@torek：感谢git filter-branch 的想法。至于squash/fixuping 提交，有时提交之间并不真正相关，因此在这种情况下这可能是不可取的。问题中的例子只是一个例子。

【参考方案1】：

rebase 将不变地更改 commit SHA，因为 rebase 是 “历史重写”

的行为

因此 - 只应在未发布的历史上进行变基。

【讨论】：

我的feature 分支在rebase 时尚未发布。我将其保密，不时将其与master 同步（以获取从mater 到feature 的更改，反之亦然），完成后，我会将其合并到@987654326 @.

这并没有真正回答原始发帖人关于如何在rebase 期间自动重写提交消息的问题。