3

我想改写我的提交信息。我使用git rebase --interactive, 并用于reword更改提交消息。我的期望是我的树将保持完全相同，但提交消息不同。相反，我最终得到了两棵树，一棵包含原始消息，一棵包含改写的消息。

我已经编辑了下面的树以消除复杂性，所以它可能不是最真实的表示出问题的地方以及原因，但它清楚地表示了我现在所拥有的。请注意，有 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

我该如何解决？

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

4

2 回答 2

3

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

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

其中 commitA是Initial ZendSkeletonApplication一个，Bis Added vendor modules，依此类推。

然后，您通过进行了一次git rebase -i提交，同时告诉 git 当前分支是. Rebase通过（因此相同的树）复制到具有新提交 ID 的新提交，并使分支标签指向新链的末尾：BEHEADbjyGuardProviderBEbjyGuardProvider

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

但它不会（也不应该）移动任何其他分支标签......所以bjy并origin/bjy保持连接到E旧链上的 commit 。

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

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

于 2014-01-21T00:36:06.180 回答
0

你做了一些pull还是fetch之后merge？这棵树看起来像这样。

git rebase用第一次提交的名称 ( )重写您的历史记录后hashes，所有后续提交都将更改，这会导致git push失败，--force但未指定。

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

要再次修复您的分支rebase，请执行 aforced push并记住永远不要再重写pushed 分支！

于 2014-01-21T00:12:41.017 回答