Git Cherry Pick创建重复的提交 [英] Git cherry pick creates duplicate commits

问题描述

在从一个分支到另一个分支挑选了一些提交之后，当稍后创建拉取请求时，我仍然看到提交.

After cherry-picking some commits from one branch to another branch, i still see commits when a pull request is created later.

例如，有一个git项目有两个分支:Dev，Release.

Say for example, There is a git project which has two branches : Dev , Release.

提交历史记录的顺序如下.

And commit history is in following order.

DEV:a1，a2，a3，a4，a5，a6

DEV : a1, a2, a3, a4, a5, a6

发布:a1，a2

现在，如果我选择从开发到发布仅提交a3和a5.现在，提交历史将如下所示.精心挑选的提交将具有新的SHA(b1& b2).

Now if i cherry-picked commits a3 and a5 alone from Dev to Release. Now the commit history will be as shown below. cherry-picked commits will have new SHA (b1 & b2).

RELEASE:a1，a2，b1，b2.

RELEASE : a1, a2, b1, b2.

稍后，如果我尝试创建从Dev到Release分支的拉取请求，我仍然会看到提交a3和a5.

Later if i try to create a pull request from Dev to Release branch, i stil see the commits a3 and a5.

但是在这种情况下，如何找到这两个分支之间的提交差异?

But in this case how can i find difference in commits between these two branches?

我看到一些文章说明变基"，但无法理解其背后的逻辑.

I saw some articles stating 'rebase' but not able to understand the logic behind it.

推荐答案

理想情况下，您首先将dev放在更新版本的基础上.

Ideally, you rebase dev on top on the updated release first.

git checkout dev
git rebase release

其背后的逻辑是Git应该检测到a3和a5与b1和b2相同:这意味着a3和a5根本不会重播.
新的dev分支(您将通过该分支创建PR)不再具有a3和a5.

The logic behind that is that Git should detect that a3 and a5 are the same as b1 and b2: meaning a3 and a5 won't be replayed at all.
The new dev branch (from which you will create a PR) won't have a3 and a5 anymore.

另请参阅:

• "
• "使用 git rebase 删除重复的，经过精心挑选的提交"

• "git merge after git cherry-pick: avoiding duplicate commits"
• "using git rebase to remove duplicate cherry-picked commits"

这篇关于Git Cherry Pick创建重复的提交的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！