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，我错过了一些非常酷/省时的功能吗？

编辑：

相关问题：Undoing a git rebase

Answer 1

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

您可以将分支机构重新命名为修订版1.57，更正所有冲突，验证并重新提交补丁。

Answer 2

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

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

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

从现在开始的一年内，您项目中的任何人都知道您真正针对修订版E而非修订版G开始使用此功能是否很重要？

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

Answer 3

只要您将“主题”合并回“主人”，您就会遇到这些冲突。因此，最好将“主题”不时地反映到“主人”上（如果你做的小步骤比你做一个大步骤更容易 - 至少是imo）。如果在合并之前进行rebase，那么所有“冒险”的东西都会在分支中发生，之后合并很容易。

Answer 4

请参阅James Bowes撰写的git rebase: keeping your branches current博客文章

什么时候需要git-rebase？

编辑：

4 个答案: