当你重写公共分支的历史时会发生什么？ [英] What happens when you rewrite history of a public branch?

问题描述

我到处读到，重写已提交的提交历史很糟糕，并会破坏其他开发人员的存储库。

我一直无法因此，如果我要重写历史记录，并且 c> git push --force ，我应该告诉其他开发者为了让他们获得最新信息？

解决方案

这可能是我见过的最好的解释： http://git-scm.com/book/ch3-6.html#The-Perils-of-Rebasing

简短的回答是其他开发人员将拉下已修改的公共存储库并尝试将这些更改与他们当前的工作进行适当合并。因为最近的祖先可能已经改变了这种合并可能很复杂并且可能需要手动执行。一个简单的例子如下：

开发人员A进行了几次提交并将其推送到服务器。开发人员B然后将这些提交合并到他们的本地分支（或从那些提交中的潜在分支）。开发人员A决定重新提交他们的旧提交并将结果推送到服务器。

这样可以有效地从开发人员B使用的服务器中删除提交，并在很大程度上替换它们现在如果开发者B再次从服务器拉下来，他们需要合并后提交的提交到他们的工作中，有效地合并相同的更改两次。

如果开发者A在rebase流程中移除了提交或修改的提交，那么开发者B的合并要复杂得多。

I read everywhere that rewriting history of commits that have been published is bad and will 'break' the repositories of the other developers.

I have been unable however to find details about what exactly will break, and how it can be fixed.

So, if I was to rewrite history and git push --force, what should I tell the other developers to do in order for them to get up-to-date?

解决方案

This is probably the best explanation I have seen: http://git-scm.com/book/ch3-6.html#The-Perils-of-Rebasing

The short answer is that other developers would pull down the modified public repository and try to merge those changes in with their current work as appropriate. Because the most recent ancestor has likely changed this merge can be complex and may need to be performed manually. A rough example follows:

Developer A makes several commits and pushes them to the server. Developer B then merges those commits into their local branch (or potentially branches from one of those commits). Developer A decides to rebase their old commits and push up the results to the server.

This effectively drops the commits from the server that developer B was using and replaces them with largely identical commits with different identifiers.

Now if developer B pulls down from the server again they need to merge the post-rebase commits into their work, effectively merging the same changes in twice.

If developer A removed commits or amended commits in the rebase process then developer B has a significantly more complicated merge to deal with.

这篇关于当你重写公共分支的历史时会发生什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！