什么时候需要 git-rebase？答案

【问题标题】：When would one need git-rebase?什么时候需要 git-rebase？
【发布时间】：2009-05-28 20:18:28
【问题描述】：

每次阅读 git-rebase 文档时，我都会迷失方向。对我来说，这感觉像是一种低级操作（阅读：黑魔法）。

引用文档：

假设存在以下历史当前分支是“主题”：
       A---B---C topic
      /
 D---E---F---G master 
从这一点上，任何一个的结果以下命令：
git rebase master 
git rebase master topic 
应该是：
A'--B'--C' 主题 / D---E---F---G主

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

一方面，它似乎“重写”了历史，好像分支从不同的点开始；本质上，提交历史将是“一堆谎言”。

还有一点，感觉不安全。我试过一次，有很多冲突，一切都乱套了。我不记得我到底是如何解决这个地狱的，但如果我没记错的话，它是在一个临时的测试分支上或类似的地方。

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

编辑：

相关问题：Undoing a git rebase

【问题讨论】：

标签： git version-control rebase

【解决方案1】：

首先，git 中没有不安全的操作。 rebase 有一个 abort 操作，所有操作都进入 reflog，因此您可以撤消任何操作。事实上，恰恰相反。

它使您可以随时随意提交，而无需在制作过程中进行“良好”构建。您发布的修订可以通过将您在此过程中采取的所有步骤压缩到单个提交中来保持干净。

我一直都在使用 rebase（通常是通过 pull，我通常配置为在 fetch 阶段之后 rebase）。不要将其视为改写历史——将其视为一种工具，让您在发布草稿之前对其进行清理。

从现在开始的一年后，让您项目中的任何人知道您确实针对修订版 E 而不是修订版 G 开始了此功能是否重要？

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

【讨论】：

您能稍微扩展一下“撤消”的内容吗？例如，您如何撤消变基？
对不起，我觉得我的一些评论被吃掉了。几乎所有更改存储库的操作都是通过添加新内容并指向它来实现的。 Reflog 会显示您之前的所有 HEAD 状态。您始终可以“重置--hard”到一个或追溯分支。除非您努力，否则这些信息在 90 天内都不会丢失。
“git中没有不安全的操作”是不正确的。虽然“git rebase”不会丢弃任何信息，但“git gc”（默认情况下，git 会定期自行调用）会。甚至在“git gc”不可撤销地破坏信息之前，“git rebase”将信息埋在 reflog 中，需要进行一些挖掘才能再次将其恢复。 Rebase 是一个非常有用的工具，但请不要误会：它是一个锋利的工具。
@mhagger：你能解释一下为什么 git-gc 会丢弃信息吗？我以为它只会删除不再引用的内容？
@sleske "git rebase" 创建新的提交并将分支指向这些，没有任何东西指向旧的提交。因此，旧的提交会受到垃圾回收的影响（除非有另一个引用指向它们）。

【解决方案2】：

您需要使用它，例如，当您想提交一个补丁来给别人修改过的代码时。例如，如果您从一个软件的 1.56 版分支出来，同时维护者移到了 1.57 版，他/她可能只接受 1.57 版的补丁。

您需要将您的分支重新设置为版本 1.57，更正所有冲突，验证并重新提交补丁。

【讨论】：

我没有使用 git 提交补丁，但是在“远程”分支上获取、合并然后 diff 有什么问题？
没什么特别的。首先需要这样做的原因是 Git（与 Mercurial 不同）不会记录给定修订是在哪个分支上进行的。在 Git 中，一些团队更喜欢拥有干净的开发/主分支历史；所以他们重新定位源分支（并可能将其压缩到目标分支上的单个修订版中）。在 Mercurial 中，如果你想拥有一个干净的分支历史，你只需过滤到那个分支；分支名称是修订的一个组成部分。（副作用是 Mercurial 中的分支是永久性的，并且一旦发布就不能重新命名。）

【解决方案3】：

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

【讨论】：

【解决方案4】：

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

【讨论】：