什么时候需要git-rebase？

Question

每次我阅读git-rebase文档时,我都迷路了.这对我来说就像是一种低级操作(读作:黑暗魔法).

引用文档:

假设存在以下历史记录,并且当前分支是"主题":

       A---B---C topic
      /
 D---E---F---G master 

从这一点来看,以下任一命令的结果:

git rebase master 
git rebase master topic 

将会:

               A'--B'--C' topic
              /
 D---E---F---G master

问题是:为什么有人想做这样的事情？

首先,它似乎是"重写"历史,好像分支开始于另一个点; 基本上,提交历史将是"一堆谎言".

还有一点,它感觉不安全.我尝试了一次,遇到了大量的冲突,一切都崩溃了.我不记得我究竟是如何解决这个问题的,但如果我没记错的话,它就是在一个临时的测试分支或类似的东西上.

另一个问题:我是否因为不知道如何使用而错过了一些非常酷/省时的功能git-rebase？

编辑:

相关问题:撤消git rebase

Answer 1

例如,当您想要将修补程序提交给其他人修改过的代码时,您需要使用它.例如,如果您从软件的修订版1.56分支,同时维护者转移到修订版1.57,他/她可能只接受修订版1.57上的修补程序.

您可以将分支重新绑定到修订版1.57,更正所有冲突,验证并重新提交补丁.

Answer 2

首先,git中没有不安全的操作.rebase有一个中止操作,所有操作都会进入reflog,因此你可以撤消任何操作.事实上,事实恰恰相反.

它允许您随时随地提交,而无需在制作一个"良好"构建的过程中进行构建.您发布的修订版可以通过将您采取的所有步骤压缩到单个提交中来实现.

我一直使用rebase(通常通过pull,我通常已经配置为在获取阶段后进行rebase).不要将其视为重写历史 - 将其视为提供工具,以便在发布之前清理草稿.

从现在开始的一年内,您的项目中的任何人都知道您真的开始使用此功能进行修订E而不是修订是否很重要G？

不必要的递归合并模糊了历史中更重要的部分.

Answer 3

一旦您将“topic”合并回“master”，无论如何您都会遇到这些冲突。因此，最好时不时地将“主题”重新定位为“主控”（如果你迈出一小步比迈出一大步更容易 - 至少在我看来）。如果在合并之前进行变基，所有“有风险”的事情都会发生在分支中，之后合并就很容易了。