Git-合并与重新基础

我已经看过了

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

我想在

主机上实现一个新功能，所以我将其分支到一个新功能分支。

我在功能上执行10次提交，而其他人在主功能上执行其他提交

我的问题是，为了测试目的，我是否希望将分支与主分支分开，但我需要使用新的主分支进行测试。
所以，我应该将主版本合并到功能中（而不是将在测试之前对主版本应用修改的功能合并到主版本中），还是执行
重设基础
？
为什么不创建一个新分支来测试合并版本？例如：

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

这里没有特别的理由做一个重基，但是如果你还没有推出你的特性分支，那也没关系。这些问题部分是关于你希望你的历史看起来如何——有些人不喜欢看到大量的合并；有些人更喜欢使用它来跟踪哪些提交对某个特定功能有贡献。
除非您已经推动了您的分支（并且您知道其他人已经克隆了您的回购），否则我仍然会做一个重基，正如我在自己的回答“重基”中提到的那样

不管测试与否，每次更新本地回购（git fetch）时，我通常都会进行一次重新基础，以确保最终合并（
功能
到
主
）是一次快速合并

因此，这不仅仅是关于您的历史的外观，而是主要是关于确保您正在开发的内容不是基于旧版本的
master
，并继续与
master
中随着时间的推移所做的最新演变相抗衡。
在我熟悉的工作流中，有一个主干和集成分支，和特色分支

我一直在重新调整“衍生品”分支机构的评级。（所谓衍生分支，我指的是远离主干的方向），并向集成分支合并

我喜欢我一直在一个分支机构工作，这个分支机构与我将要集成的分支机构有着相同的历史。我喜欢合并成为一种快进方式，因此，我知道我刚才合并的内容与我在分支中测试的内容完全相同。
当两个开发人员提交相同的回购协议时（这将产生冲突），您可以通过创建合并提交来合并这两个提交，或者您可以在另一个提交的基础上重新设置一个提交（您的）的提交。重新设置基址总是比生成合并提交更好。
这有待讨论。我会做一个重新基址。你看到的链接中的顶部答案提供了一个在你的用例中重新基址的明确建议。将来，请使用更具描述性的标题，更清楚地解释你试图解决的问题。我想有一个“开发”分支一起测试特性，然后将其放在master上进行生产，在这种情况下是一种好的做法吗？因此，合并与重基的问题只是关于您希望提交历史记录如何？我同意这个选项（合并到新分支中），所以+1。但我仍然主张在下面的回答中使用rebase。@user2316341如果您必须集成（合并）多个功能分支，以查看它们是否都能协同工作，“dev”分支是有意义的。但是如果一次只有一个功能分支。。。这增加了复杂性，但收效甚微。所以你说我应该总是在大部分时间重新设置基址，但如果我已经推动了我的分支，就不应该这样做。为什么呢？已经推出分支的问题是什么？@user2316341 a rebase重写了SHA1的历史。在这种情况下，您必须
gitpush--force
，以替换已经由rebase生成的新历史推送的历史。如果没有人在使用您的分支，那么这并不是什么大问题，而rebase是迄今为止最简单、最安全的解决方案，它是人为地向中间分支添加合并。@user2316341请参见此问题的示例。