经常有人说,你不应该重置已经推送过的提交记录。这是什么意思呢?
关于你的问题,可以在标题为 "The Perils of Rebasing" 的部分找到具体答案。以下是该部分的引用:
当你重置工作时,你是在放弃现有的提交记录,并创建新的类似但不同的提交记录。如果你将提交记录推送到某个地方并且其他人将其拉下来并在其基础上工作,然后你使用 git rebase 重写这些提交记录并再次将其推送上去,你的协作者将需要重新合并他们的工作,当你尝试将他们的工作拉回到你的工作中时,事情会变得混乱。
更新:
根据您下面的评论,看起来您在 Git 工作流程方面遇到了麻烦。以下是一些可能有所帮助的参考资料:
gitworkflows
手册:请参见“向上合并”和“主题分支”重新定位基底会重写历史记录。如果没有人知道那段历史,那就没问题了。然而,如果那段历史是公开的,那么在Git中重写历史记录的方式就和在现实世界中一样:你需要一个阴谋。
阴谋真的很难维持下去,所以最好一开始就避免在公共分支上重新定位基底。
请注意,还有一些成功的阴谋案例:Junio C. Hamano的git存储库(Git SCM的官方存储库)中的pu
分支经常被重新定位基底。这项工作的方式是,几乎每个使用pu
的人都已订阅了Git开发者邮件列表,并且pu
分支被重新定位基底的事实在邮件列表和Git网站上广泛宣传。
pu
分支是如何在(public)工作流中使用rebase的一个非常有用的例子。对于那些不熟悉它的人,一般的想法是重新设置主题分支(topic branches),这些分支没有任何在next
(即将合并到主分支之前的不稳定分支)中的提交,然后通过重置到next
,再将所有主题分支合并来重建pu
分支。(来源:Documentation/howto/maintain-git.txt http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/maintain-git.txt;h=d527b307707c676e82a08f18cb9fdd7d3abcb228;hb=HEAD) - CascabelRebase(变基)会改变您的存储库历史记录。如果您将提交推送到世界上,即使它们对其他人可用,然后更改提交历史记录的视图,与拥有旧历史记录的任何人一起工作将变得困难。
Rebase considered harmful 是一个很好的概述,我认为。
git rebase
(--interactive?)来重写历史记录,这是失败的必然结果。另一方面,如果我已经将某些更改重新定位到主题分支(从分支X),并将其推送,那么在另一个开发人员更改主题分支后再次重新定位就是完全正常的。基本上,我已经使用了“合并”相当长的时间,但我们和http://darwinweb.net/articles/86处于同样的境地,历史记录几乎无法使用。 - Hemant Kumar