9

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

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

RELEASE : a1, a2

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.

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.

Sri
  • 163
  • 3
  • 12
  • 1
    That's exactly what `cherry-pick` is supposed to do: `Given one or more existing commits, apply the change each one introduces, recording a new commit for each. ` (from [here](https://git-scm.com/docs/git-cherry-pick#_description)) – kowsky Mar 29 '17 at 07:35

1 Answers1

9

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

git checkout dev
git rebase release

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.

See also:

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250