我为什么要做git rebase？

Question

我见过很多人谈论git rebase它和它做了什么,例如Hg:如何做一个像git的rebase一样的rebase,人们谈论它实现了什么(给出了线性历史),例如,这里Git rebase失去了历史,那么为什么要反思？但我无法理解你为什么要这样做.

回顾并修改你的提交历史似乎是一笔巨大的开支(这肯定会涉及与n路冲突的一些丑陋的合并).我可以想象它可能会产生误导的情况(例如,如果两个人以不同的方式解决同样的问题,但历史并没有表明他们的工作是平行发生的;似乎很容易导致批评和怨恨在一些高压编码环境中).

您获得的是一个更容易理解但不正确的历史图表.是什么值得努力？

提前致谢.

Answer 1

在短时间内(小时或分钟)推送单个提交或少量提交时,Rebase最有用.

在推送到共享服务器之前,必须首先同时提取对原始HEAD的提交 - 如果不这样做将创建非快进推送.这样做,可以在merge(git pull)或rebase(git pull --rebase)操作之间进行选择.合并选项虽然在技术上更具吸引力,但会创建一个额外的合并提交.对于一个小的提交,每次更换两次提交的出现实际上使历史少可读,因为合并操作从提交的消息分心.

在典型的共享开发树中,每个开发人员都会通过执行某些变体来推送到共享分支git pull; <resolve conflicts>; git push.如果他们使用git pull没有--rebase,什么情况是,几乎每一个承诺结束伴随着合并提交,即使没有并行发展的真实情况.这创造了一个交织的历史,从实际上是一个线性的提交序列.因此,git pull --rebase对于由于开发时间短而导致的小变化,这是一个更好的选择,而合并则保留用于长期特征分支的集成.

所有这些都适用于重新定位本地提交,或者重新设置由密切相关的同事(坐在同一个房间)共享的短期功能分支.一旦提交推定期,然后被别人分支,它应该永远不会被重建基础.

Answer 2

TLDR：变基策略不值得付出努力。

rebase 策略的唯一好处是线性历史，仅此而已。

现在问自己一个问题：你检查过 git 历史记录多少次才能弄清楚某些事情？你能用合并策略来解决这个问题吗？

我的回答是几乎从不，是的，合并策略不是很好，但已经足够好了。

但这是变基策略的成本：

• 每次其他人将更改推送到主分支时，您都必须重新调整更改的基础，这对于 3 个开发人员来说没问题，但对于更多的开发人员来说，这会成为一个问题，在等待管道构建时添加它，合并任何东西都会变得可怕。
• 您一次只能“合并”一个更改到主分支，所有其他更改都必须首先重新建立基础，然后再次通过管道构建（额外延迟）。
• 必须分别为每个提交解决冲突，如果我知道我在下一次提交中更改了它，那么解决旧/过时提交的冲突对我来说是疯狂的。
• 如果你搞砸了变基，你会将所有修复添加到最后一次提交，而所有旧的修复都会被破坏。另一种选择是一切重新开始。
• 你必须在变基后强制推送到你的分支，如果你搞砸了，你可能会花很长时间扫描引用日志。
• 如果您的分支上有两个以上的提交，您可能会在变基之前压缩它们以减少工作量，并且会丢失宝贵的提交历史记录。

我已经尝试过这两种方法，当我比较优点和缺点时，Rebase 策略不值得付出努力。