Question

我的场景：我尝试压缩3次提交，2次的消息与分支前的最后一次提交相结合，我想删除虚拟提交消息。

（对不起，下面的示例不是终端的直接副本，只是我的解释。）

我连续7次提交。其中3个是我想在将我的分支合并回主人之前压缩的。

af7d12c31e123023425a7b6f88bd3d6f43103358 dummy commit 3
69ec87cf490313086627df5224a1bcdbd3e9addd KEEP THIS COMMIT 4
fd6c843d59451c017628d03f3b4674045f06e54a KEEP THIS COMMIT 3
9ec44b48384373cbc8571b6beba7fd094db03e93 KEEP THIS COMMIT 2
53b8a217a4dcc85fb74e7c57861253f801ff882a KEEP THIS COMMIT 1
914dc32f7882b2b459e46b35a9314aef1c6824ba dummy commit 2
290f261f9d1541967f491fe8cba0fdd085ad5c20 dummy commit 1 (1st one in branch)
98dfb5299b122e496aeae29142038894488f0871 LAST COMMIT BEFORE BRANCHING

我跑了

git rebase --interactive 98dfb5299b122e496aeae29142038894488f0871

然后我将3个虚拟提交（1,2,3）设置为压扁。保存并重新安装完毕。

现在，当我“git log”时，98dfb5299b122e496aeae29142038894488f0871的提交消息如下所示：

commit 98dfb5299b122e496aeae29142038894488f0871
Author: <me>
Date:   Thu Apr 25 14:51:28 2013 -0700

    LAST COMMIT BEFORE BRANCHING

    dummy commit 1

    dummy commit 2

我从同一次提交中再次运行git rebase，并将该提交更改为“reword”并更改了消息，但它没有任何效果。

我还没有推送任何这些更改，只是在我的分支上本地提交。

我是否需要再次重新，但要在分支之前从LAST COMMIT的父级进行重新定位？

Answer 1

首先，请注意几点：

如果98dfb529是分支前的最后一次提交（也就是说，它出现在master和分支中），那么将分支的第一次和第二次提交设置为“squash”（{{ 1}}和290f261f）有效地将分支点向前移动了一步。这是因为914dc32f在您的分支中不再存在，并且已被替换为被压扁的98dfb529 + 98dfb529 + 290f261f（我们称之为914dc32f ）。但是，aaaaaaaa仍存在于主人身上。
然后您决定在98dfb529上执行reword。您更改了提交消息。此更改触发了提交哈希本身的更改，因此现在您的分支包含aaaaaaaa而不是bbbbbbbb。但是，aaaaaaaa仍然存在，即使它没有被任何分支直接引用：它将在下次git触发悬空提交的垃圾收集时被删除。因此，aaaaaaaa仍会显示旧消息。

总结一下，这可能是你目前的情况：

git log aaaaaaaa

壁球后更改先前的提交消息，而不是推送

1 个答案: