我的场景:我尝试压缩 3 次提交,来自 2 次的消息在分支之前与最后一次提交 merge ,我想删除虚拟提交消息。
(抱歉,下面的样本不是直接从终端复制的,只是我的解释。)
我连续提交了 7 次。其中 3 个是我想在将我的分支 merge 回 master 之前压缩的。
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) 设置为压缩。保存并 rebase 完成。
现在,当我“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
我从同一个提交 98dfb5299b122e496aeae29142038894488f0871 再次运行 git rebase,并将该提交更改为“reword”并更改了消息,但它没有任何效果。
我还没有推送任何这些更改,只是在我的分支上本地提交。
我是否需要从 LAST COMMIT BEFORE BRANCHING 的父级再次 rebase ?
最佳答案
首先,一些注意事项:
如果
98dfb529
是分支前的最后一次提交(也就是说,它同时出现在 master 和您的分支中),则将您分支的第一次和第二次提交设置为“squash” (290f261f
和914dc32f
) 有效地将分支点向前移动了一步。这是因为98dfb529
在您的分支中不再存在,它已被压扁的98dfb529
+290f261f
+914dc32f
(我们称之为aaaaaaaa
)。但是,98dfb529
仍然存在于 master 中。然后您决定对
aaaaaaaa
进行改写
。您更改了提交消息。此更改触发了提交哈希本身的更改,因此现在您的分支包含bbbbbbbb
而不是aaaaaaaa
。然而,aaaaaaaa
仍然存在,即使它没有被任何分支直接引用:它会在下次 git 触发悬空提交的垃圾收集时被删除。因此,git log aaaaaaaa
仍会显示旧消息。
回顾一下,这可能是您目前的情况:
(..your branch..)
|
* af7d12c3 // Note however that these five commits
* 69ec87cf // have now a different hash, because
* fd6c843d // the history has been changed: when
(..master..) * 9ec44b48 // the parent of a commit changes, then
| * 53b8a217 // the child's hash changes as well.
* 98dfb529 * aaaaaaaa * bbbbbbbb
| | |
| __________/____________/
|/
(... previous history ...)
关于git - 压缩后更改先前的提交消息,而不是推送,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16309602/