在以下文档中，peepcode-git.pdf位于https://github.com/pluralsight/git-internals-pdf/releases，第39页注释了rebase的不同用例。特别是这句话：
"如果你有一个巨大的项目或想法——比如将整个代码库重构为最新版本的框架，或者更换数据库供应商等等，你就创建了一个长期的分支，不断地重新构建它的基础，使其与其他开发保持一致，一旦每件事都经过测试并准备好了，就将它与你的主库合并">
问题是电子书中的例子介绍了rebase的想法和抽象应用程序，但它没有提供具体的命令，用户可以根据它复制例子；连续再基底"；部分通常，当我重新设定基数时，我发现它在以下情况下有效：
- 我正在处理一个分支，我不知道要提交多少次才能到达解决方案。通常，当我尝试一些代码但它不起作用时，我会在提交日志中写一条注释来压缩提交，因为它没有任何价值。当我最终弄清楚代码所需的内容状态时，我将分支重新设置为只包含重要的提交，并按规定挤出其他提交。然后，我通过rebase将这些更改重放到主分支上
然而，如果我正在处理一项长任务，我不太理解将main重新定基到我的分支上以与之保持同步的想法，因为这意味着main中的每个提交都将被回放到我的功能分支上的新提交中，但它将是完全相同的内容状态。这似乎违反了直觉，因为提交哈希更改时会丢失有价值的信息。此外，当将特性分支工作放到main上时，它会将所有更改重放到main上，包括在main上重复提交(使用不同哈希(。我认为将main不断合并到本地分支以保持其与main同步更有意义，然后在完成后将其重新绑定到main。这将有助于将合并基础保持在较新的点，并减少在main上重播的提交数量。我错过了什么？
这是一个简单的误解。这个建议不是你想象的那样：
然而，如果我正在处理一项长任务，我不太理解将main重新设置为分支以保持同步的想法。。。
相反，您会定期将您的分支重定为主。例如：
git switch my-long-lived-branch
git fetch
git rebase origin/main
请注意，如果有人在main上更改了与您在分支上更改的文件相同的文件，则在执行这种类型的重新基准时可能会发生冲突。
您还提到：
当我最终弄清楚代码的所需内容状态时，我将分支重新调整为仅重要的提交，并按所述压缩其他提交。
这是另一种重新基准；一个交互式的rebase，目的是修复正在进行的提交。您可以在任何时候针对合并基础(开始提交分支(单独执行此操作，而不会发生冲突：
# if you know the commit ID of the parent of your first commit:
git rebase -i parent-ID-of-your-first-commit
# or if you have many commits and don't want to bother looking it up
git rebase -i $(git merge-base HEAD origin/main)
至于你关于合并而不是重组的建议：
我认为将main不断合并到本地分支以保持其与main同步更有意义，然后在完成后将其重新绑定到main。
这会很好，分支rebase也是如此，可以让您的分支使用最新的origin/main。我认为这是出于个人喜好。在这种情况下，我个人更喜欢重新定基而不是合并，如果你是交互式的重新定基，你也可以定期进行分支重新定基。