Git rebase 功能分支在向开发/主分支的拉取请求中弄乱了提交

Question

我有以下场景：

• 主分支：生产中的内容，可以包含修补程序
• Develop-branch：我的开发人员用来创建拉取请求的分支
• 功能分支：我们为开发人员正在实现的功能创建的分支。

开发人员完成工作后，他会在开发分支上创建拉取请求。 批准后，我们​​将功能分支压缩合并到开发分支，以便不包括开发人员在功能分支上所做的所有提交。 这使我们能够在开发分支上拥有清晰干净的 git 历史记录。

有时功能分支需要从 develop 分支进行 rebase，这就是问题开始的地方。

如何避免这种情况，以便 PR 仅包含来自功能分支的实际提交？

Answer 1

我怀疑这是在修补程序发布后从 master 重新开发基础之后发生的。

考虑以下场景：

master   A->B->C
                \
develop          D
                  \
feature A          E

然后，您会在master 、 F 中获得一个修补程序，并对其进行 rebase develop 。 变基创建了一个具有不同散列的“新”提交 (D')，因此从 git 的角度来看，D 和 D' 是两个独立且不相关的提交。 D 仍然存在，并且 C 是它的父级，但它不再处于develop - 仅在feature A ：

master   A->B->C->F
                \  \
develop          \  D'
                  \
feature A          D->E

因此，如果您尝试将feature A off develop ，如果您不进行交互式重新设置，则 git 将无法识别 D 和 D' 是相同的提交，您最终会得到以下结果：

master   A->B->C->F
                   \
develop             D'
                     \
feature A             D->E

为了解决这个问题，当从develop重新绑定feature A时，以交互方式执行并告诉 git 删除D ，因为您知道它与 D' 相同。