我看过你什么时候使用 git rebase 而不是 git merge？ .
但我想确定在这种情况下选择哪种解决方案：
我想实现一个新特性，master所以我将它分支到一个新的特性分支。
我在 Feature 上做了 10 次提交，而其他人在 Master 上做了其他提交。
我的问题是我是否想将我的分支与 Master 分开以进行测试，但我需要使用集成的新 Master 提交对其进行测试。那么，我应该将 Master 合并到 Feature 中（而不是将 Feature 合并到 Master 中，这将在我的测试之前将我的修改应用于 master ）还是做一个rebase？
为什么不创建一个新分支来测试合并后的版本呢？例如：
git checkout -b test-merged-feature master
git merge my-feature
[... do your testing ..]
没有特别的理由在这里做一个 rebase，但如果你还没有推送你的特性分支，那也很好。这些问题部分是关于你希望你的历史看起来如何——有些人不喜欢看到很多合并；有些人更喜欢它作为一种跟踪哪些提交对特定功能做出贡献的方式。
除非你已经推送了你的分支（并且你知道其他人已经克隆了你的仓库），否则我仍然会做一个 rebase，正如我在我自己的回答“ git rebase vs git merge ”中提到的那样。
测试与否，我通常在每次更新本地 repo (git fetch) 时做一个 rebase，以确保最终的合并 ( Featureto master) 将是一个快进的合并。
所以这不仅仅是关于你的历史看起来如何，而是主要是为了确保你正在开发的东西不是基于旧版本的，并随着时间的推移master不断地与最新的演变相抗衡。master
在我熟悉的工作流程中，有一个主干、集成分支和功能分支
我一直在转向“衍生”分支。（通过派生分支，我的意思是远离主干的方向），并向集成分支合并。
我喜欢我总是在一个与我将要集成的分支具有相同历史的分支中工作。我喜欢合并变得快进，所以，我知道我刚刚合并的内容与我刚刚在我的分支中测试的内容完全相同。
当 2 个开发人员提交到同一个 repo 时（这会产生冲突），您可以通过创建合并提交来合并 2 个提交，或者您可以将 1 个提交（您的）重新设置在另一个提交之上。最好是重新设置基准而不是生成合并提交。