Question

我想重新提交我的提交消息。我使用git rebase --interactive，并使用reword来更改提交消息。我的期望是我的树将保持完全相同，但具有不同的提交消息。相反，我最终得到了2棵树，其中一棵包含原始信息，一条包含重写信息。

我编辑了下面的树以消除复杂性，所以也许它不是最糟糕的代表，哪里出了问题，为什么，但它清楚地代表了我现在拥有的东西。请注意，有4条消息基本相同，但略有改动。我向你们保证，三角洲是相同的。

* 56bb877 (HEAD, bjyGuardProvider) BjyRuleAdapter:  checkpoint!  (same as 0e1f985)
* 6b765f1 Base:  Added a new FedcoUser local module (same as 47e1cf9)
* bbfb764 Base:  Added Zend Studio/Server deployment descriptor files (same as 6b7cc21)
* 8ee08b9 General:  Added vendor modules (no configuration applied) (same as 4648e11)
| * 0e1f985 (origin/bjy, bjy) Checkpoint:  BjyAuthorize works
| * 47e1cf9 Added a new FedcoUser local module
| * 6b7cc21 Added Zend Studio/Server deployment descriptor files
| * 4648e11 Added vendor modules (no configuration applied)
|/
* e539e7a Initial ZendSkeletonApplication

我该如何解决这个问题？

如果它绝对有帮助，我可以在某处提供完整树的链接，或提供任何其他信息。

Answer 1

这实际上是rebase的正常结果，它不会修改现有的提交，而是添加新的提交。你有这个：

A - B - C - D - E   <-- origin/bjy, bjy, HEAD=bjyGuardProvider

其中，提交A为Initial ZendSkeletonApplication，B为Added vendor modules，依此类推。

然后您通过git rebase -i执行了B次提交E，而HEAD告诉git当前分支是bjyGuardProvider。 Rebase将B通过E（因此相同的树）复制到具有新提交ID的新提交，并使分支标签bjyGuardProvider指向新链的末尾：

A - B - C - D - E   [the old tip commit]
  \
    B'- C'- D'- E'  <-- HEAD=bjyGuardProvider

但它不会（也不应该）移动任何其他分支标签...因此bjy和origin/bjy仍然附加到提交E，旧链。

如果您移动自己的bjy标签（手动）并将其强制推送到origin上的git存储库，您可以（取决于允许的origin是多少）能够将所有三个标签移动到指向提交E'。旧链将不再具有任何标签，并且将有资格进行垃圾收集，如果这些确实是用于命名这些提交的唯一三个标签。

如果某个第三个存储库有origin存储库的副本，那么他们仍然会有旧标签和旧提交，并且您需要让它们移动他们的标签。正如@poke在评论中指出的那样，这就是为什么不鼓励重新发布已发布的提交。（“应该”和“不应该”最终是价值判断 - 让所有其他存储库同步，值得获益，不管它是什么的痛苦？ - 但痛苦就像你现在所看到的那样。）

Answer 2

之后你做了一些pull或fetch和merge吗？树看起来像这样。

使用git rebase重写您的历史记录后，第一次提交的名称（hashes）和所有后续提交都会更改，这会导致git push失败，--force不会指定。

之后

pull新的提交将重新引入所有应该更改的提交。

要修复您的分支，您可以再次rebase，执行forced push并记住再也不要重写push ed分支！

git rebase --interactive（reword）给我留下了两棵带有相同提交消息的树

2 个答案: