我看到很多人谈论 git rebase 以及它的作用，例如Hg: How to do a rebase like git's rebase 人们谈论它所取得的成就（给出线性历史），例如这里Git rebase loses history, then why rebase? 但我不明白你为什么要这样做。
返回并修改您的提交历史似乎是一项大费用（这肯定涉及一些丑陋的合并与 n 路冲突）。而且我可以想象它可能会非常误导的情况，（例如，如果两个人以不同的方式解决同一个问题，但历史并没有显示他们的工作是并行发生的；似乎也很容易引起批评和怨恨在一些高压编码环境中）。
您获得的是更容易理解但不正确的历史图表。是什么让这值得付出努力？
提前致谢。
【问题讨论】：
标签： git git-rebase
在推送单个提交或在短时间内（小时或分钟）开发的少量提交时，Rebase 最有用。
在推送到共享服务器之前，必须先将同时提交到源的 HEAD 的提交拉取——否则会创建非快进推送。这样做时，可以在合并 (git pull) 或变基 (git pull --rebase) 操作之间进行选择。合并选项虽然在技术上更具吸引力，但会创建额外的合并提交。对于小型提交，每次更改出现两次提交实际上使历史记录不太可读，因为合并操作分散了提交消息的注意力。
在典型的共享开发树中，每个开发人员最终都会通过执行git pull; <resolve conflicts>; git push 的一些变体来推送到共享分支。如果他们使用git pull 而不使用--rebase，那么几乎每个 提交最终都伴随着一个合并提交，即使没有真正进行并行开发。这从实际上是线性提交序列中创建了一个相互交织的历史。出于这个原因，git pull --rebase 对于短期开发导致的小更改是一个更好的选择，而合并则保留用于集成长期存在的功能分支。
所有这些都适用于变基 本地 提交，或变基由紧密联系的同事（坐在同一个房间）共享的短期功能分支。一旦提交被定期推送到其他分支，它应该永远被重新设置。
【讨论】：
git log --no-merges
git log --no-merges 很好，但您确实希望看到tig 和gitk 等工具中的合并。在我的团队中，我们禁止了 trivial 合并，即合并单个小提交的合并。 （而且禁令是以一种纯粹的、ahem、社交的方式执行的。）
执行变基通常不涉及比合并更多的冲突解决，因此与之相比的费用是最小的（实际上只是重放提交所需的时间）。
与大多数与 git 相关的事情一样，只有在知道 什么 你在做什么以及 为什么 你要这样做的情况下，你才应该重新设置基准。以下是我进行 rebase 的一些原因：
git rebase 让我在提交时一次解决这些冲突，使其更容易理解，并在我进行时进行测试。如果我关心维护合并提交，我可以在之后返回到分支的非重新定位版本，将其与上游合并，然后使用针对重新定位版本的差异作为冲突解决合并提交。【讨论】：
TLDR：rebase 策略不值得努力。
变基策略的唯一好处是线性历史，仅此而已。
现在问自己一个问题，你检查了多少次 git 历史以找出一些东西？你能用合并策略解决它吗？
我的回答几乎是从不，是的，合并策略不是很好，但已经足够好了。
但这是变基策略的成本：
我都尝试过，当我比较利弊时，Rebase 策略不值得努力。
【讨论】：