Laz*_*zer 18 git algorithm version-control dvcs
在本文中,作者使用此图解释了变基:
alt text http://eagain.net/articles/git-for-computer-scientists/git-history.7.png
Rebase:如果您还没有发布您的分支机构,或者已经清楚地告知其他人不应该以此为基础,那么您可以选择其他方式.您可以重新分支您的分支,而不是合并,您的提交将被另一个具有不同父级的提交所取代,并且您的分支将被移动到那里.
而正常的合并将如下所示:
alt text http://eagain.net/articles/git-for-computer-scientists/git-history.5.png
所以,如果你重订,你只是失去了一个历史状态(这将是垃圾回收在将来某个时候).那么,为什么有人想要做一次变革呢？我在这里错过了什么？
Cas*_*bel 33
在各种情况下,您可能希望重新定义.
您在不同的分支上开发特征的一些部分,然后意识到它们实际上是思想的线性进展.将它们重新定位到该配置中.
你从错误的地方分叉一个话题.也许这太早了(你需要后来的东西),也许为时已晚(它实际上也适用于以前的版本).将它移动到正确的位置."太迟"的情况实际上无法通过合并修复,因此rebase是至关重要的.
您想测试分支与另一个分支的交互,但由于某种原因不想合并.例如,您可能希望查看哪些冲突突然提交,而不是一次性完成.
这里的一般主题是过度合并会使历史变得混乱,如果你最初没有得到你的分支/合并计划,那么变基是一种避免它的方法.太多的合并会使人难以追踪历史,也会使人们更难使用像这样的工具git-bisect.
还有许多案例促使交互式变基:
多次提交应该是一次提交.
提交(不是当前提交)应该是多次提交.
提交(不是当前提交)在其中或其消息中存在错误.
应删除提交(不是当前提交).
提交应该重新排序(例如,更加逻辑地流动).
虽然你在做这些事情时"失去了历史",但事实是你只想发表干净的工作.如果仍未发布某些内容,可以对其进行重新定位,以便将其转换为您应该提交的方式.这意味着公共存储库中的最终版本将是合乎逻辑且易于遵循的,而不是保留开发人员在此过程中遇到的任何打嗝.
