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

Question

我有以下场景:

主分支:正在生产的东西，可以包含修补程序

Develop-branch:我的开发人员用来向

创建 pull 请求的分支

功能分支:我们为开发人员正在实现的功能创建的分支。

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

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

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

Answer 1

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

考虑以下场景:

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

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

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

因此，如果您尝试重新定位 feature A关闭 develop ，如果您不进行交互式 rebase ，git 将无法识别 D 和 D' 是相同的提交，并且您最终会得到以下结果:

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

为了解决这个问题，在 rebase 时 feature A来自 develop , 以交互方式执行并告诉 git 删除 D ，如您所知，它与 D' 相同。