协慌网

什么时候建议使用git rebase与git merge ？

成功改造后我还需要合并吗？

精简版

• Merge 在一个分支中获取所有更改，并在一次提交中将它们合并到另一个分支中。
• Rebase 说我想要分支的点移动到一个新的起点

所以你什么时候使用其中任何一个？

合并

• 假设您已经创建了一个分支，用于开发单个功能。当您想要将这些更改带回 master 时，您可能需要合并 （您不关心维护所有临时提交）。

变基

• 第二种情况是，如果您开始进行一些开发，然后另一位开发人员进行了无关的更改。你可能想拉，然后变基到从回购目前的版本为基础修改。

这很简单，你说使用另一个分支作为你工作的新基础 。

如果你有一个分支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

这一次，由于主题分支具有相同的 master 提交以及具有新功能的提交，因此合并将只是一个快进。

为了补充我 对 TSamper提到的答案 ，

• 在合并之前，一个 rebase 通常是一个好主意，因为这个想法是你在你的分支Y集成你将合并的分支B的工作。
  但同样，在合并之前，你解决了你的分支中的任何冲突（即：“rebase”，如 “从分支B的最近点开始重放我在我的分支中的工作”）
  如果正确完成，从分支到分支B的后续合并可以快速进行。

• 合并直接影响到目标分支B ，这意味着合并更好是微不足道的，否则分支B可以很长时间恢复到稳定状态（解决所有冲突的时间）

在一次变革之后合并的重点是什么？

在我描述的情况下，我将B绑定到我的分支上，只是为了有机会从B最近点重播我的工作，但是留在我的分支中。
在这种情况下，仍需要合并才能将我的 “重播” 作品带到B 。

另一种情况（例如在 Git Ready 中描述 ）是通过 rebase 将您的工作直接带入B （这确实可以保存您所有的好提交，甚至可以让您通过交互式 rebase 重新排序它们）。
在那种情况下（你在 B 分支中进行重组），你是对的：不需要进一步的合并：

我们没有合并也没有重新定义的默认 git 树

我们通过变基来获得：

第二种情况就是：如何将新功能重新用于主服务器。

我的观点是，通过描述第一个 rebase 场景，提醒大家一个 rebase 也可以作为一个初步步骤（即 “让新功能重新成为主人”）。
您可以使用 rebase 首先将主要 “引入” 新功能分支：rebase 将重播来自HEAD master新功能提交，但仍然在新功能分支中，有效地从旧主提交中移动分支起点到HEAD-master 。
这允许您解决您的分支任何冲突（意思，隔离，同时允许主继续同步发展，如果你的解决冲突的阶段时间过长）。
然后，你可以切换到主和合并new-feature （或重订new-feature到master ，如果你想保留你的提交完成new-feature的分支）。

所以：

• “rebase vs. merge” 可以被视为导入作品的两种方式，比如master 。
• 但是 “rebase then merge” 可以是一个有效的工作流程，可以首先独立解决冲突，然后恢复你的工作。