Git - Merge vs rebase

Question

我已经看过When do you use git rebase instead of git merge? 了。

但我想确定在这种情况下应该选择哪种解决方案：

我想在master上实现一个新特性，所以我将其分支到一个新特性分支。

我在功能上做了10次提交，而其他人在Master上做了其他提交。

我的问题是，为了测试的目的，我是否希望将我的分支与Master分开，但我需要使用集成的新Master commits来测试它。那么，我是否应该将主功能合并到功能中(而不是将功能合并到主功能中，从而在测试之前将我的修改应用于主功能)或执行rebase

Answer 1

为什么不创建一个新的分支来测试合并后的版本？例如：

git checkout -b test-merged-feature master
git merge my-feature
[... do your testing ..]

没有特别的理由在这里做一个rebase，但是如果你还没有推出你的feature分支，那也没问题。这些问题在一定程度上是关于你希望你的历史是什么样子的--有些人不喜欢看到太多的合并；有些人更喜欢它作为一种跟踪哪些提交对特定功能做出贡献的方式。

Answer 2

除非你已经推送了你的分支(你知道其他人已经克隆了你的repo)，否则我仍然会做一个rebase，就像我在我自己的答案"git rebase vs git merge“中提到的那样。

无论测试与否，我通常会在每次更新本地存储库(git fetch)时执行一次rebase，以确保最终的合并(从Feature到master)是快进的。

因此，这不仅仅是关于你的历史是什么样的，而是主要是要确保你正在开发的东西不是基于旧版本的master，并且随着时间的推移，继续与master中完成的最新发展保持一致。

Answer 3

在我熟悉的工作流中，有主干、集成分支和功能分支

我一直在向“衍生”分支机构靠拢。(派生分支，我指的是远离主干的方向)，并向集成分支合并。

我喜欢我总是在一个与我将要集成的分支具有相同历史的分支中工作。我喜欢合并成为快进，因此，我知道我刚刚合并的内容与我刚刚在分支中测试的内容完全相同。