每次我阅读 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？
相关问题：撤消 git rebase
例如，当您想提交一个补丁到其他人修改的代码时，您需要使用它。例如，如果您从一个软件的 1.56 版分支出来，而同时维护者移到了 1.57 版，他/她可能只接受 1.57 版的补丁。
你可以将你的分支变基到 1.57 版，更正所有冲突，验证并重新提交补丁。
首先，git中没有不安全的操作。rebase 有一个 abort 操作，所有操作都进入 reflog，因此您可以撤消任何操作。事实上，情况恰恰相反。
它使您可以随时随意提交，而无需在制作过程中进行“良好”构建。您发布的修订可以通过将您在此过程中采取的所有步骤压缩到单个提交中来保持干净。
我一直在使用 rebase（经常通过 pull ，我通常配置为在 fetch 阶段之后 rebase）。不要将其视为改写历史——将其视为为您提供一种工具，让您在发布草稿之前对其进行清理。
从现在开始的一年后，您项目中的任何人都知道您真正开始此功能是针对修订E而不是修订是否重要G？
不必要的递归合并掩盖了历史中更重要的部分。
一旦您将“主题”合并回“主”，无论如何您都会遇到这些冲突。因此，最好不时将“主题”重新定位为“主”（如果你做小步骤比做一大步更容易 - 至少在imo中）。如果你在合并之前变基，所有“有风险”的事情都会发生在分支中，之后合并很容易。
请参阅git rebase：让您的分支保持最新的 James Bowes 博客文章