你什么时候使用git rebase而不是git merge？
什么时候推荐使用git rebase与git merge ？
成功转型后，我还需要合并吗？
简洁版本
那么你什么时候使用任何一个？
合并
变基
很简单，你可以用另一个分支作为你工作的新基地 。
如果您有例如分支master并且您创建了一个分支来实现新功能，比如说您将其命名为cool-feature ，那么主分支当然是您的新功能的基础。
现在在某个时候您想要添加您在master分支中实现的新功能。 您可以切换到master并合并cool-feature分支：
$git checkout master
$git merge cool-feature
但是这样一个新的虚拟提交被添加，如果你想避免意大利面条历史，你可以重新分配 ：
$git checkout cool-feature
$git rebase master
然后在master合并它：
$git checkout master
$git merge cool-feature
这一次，由于主题分支具有相同的主提交以及提交新功能的提交，因此合并将仅仅是一个快进。
为了补充TSamper提到的我自己的答案，
在合并之前进行重新分配通常是一个好主意，因为这个想法是，您将分支B的工作集成到您的分支Y ，您将合并分支B
但是，再次合并之前，您可以解决分支中的任何冲突（即：“rebase”，例如“从分支B的最近一点开始，在我的分支中重放我的工作）
如果正确完成，从分支到分支B的后续合并可以快进。
合并直接影响到目的地分支B ，这意味着合并更好是微不足道的，否则分支B可能很长时间才能恢复到稳定状态（解决所有冲突的时间）
重组后的合并点？
在我描述的情况下，我把B重新分配到我的分支上，只是为了有机会从B最近点重放我的作品，但是留在我的分支中。
在这种情况下，合并仍然需要将我的“重播”作品带到B 。
另一种情况（例如Git Ready中描述）是通过rebase将您的工作直接带到B （这可以节省所有漂亮的提交，甚至可以让您有机会通过交互式rebase重新排序）。
在这种情况下（当你在B分支的时候重新绑定），你是对的：不需要进一步合并：
默认情况下，我们没有合并或重新设计一个git树
我们通过重新贴牌获得：
第二种情况全是关于：我如何将新功能重新带回主服务器。
我的观点是，通过描述第一个转型的情景，就是提醒大家，转型也可以作为一个初步步骤（即“将新特征带回主”）。
您可以使用rebase来首先将新功能分支中的master“带入”：rebase将重播来自HEAD master新功能提交，但仍然位于新功能分支中，有效地将分支起点从旧主提交以HEAD-master 。
这样可以解决分支中的任何冲突（也就是说，如果冲突解决阶段花费太长时间，则允许主控并行地继续进化）。
然后，您可以切换到主控并合并new-feature （或者如果要保留new-feature分支中的提交，则将new-feature绑定到master ）。
所以：
master 。