Avoid repeated commits when the cherry is selected from the master into the branch, then merges from the branch back to the master

Question

I have two branches in git, master / and 1.7 /. I support some fixes from master / to 1.7 / using cherry pick. (I do not use merging because I only need some changes.):

$ git checkout 1.7 $ git cherry-pick -x <initial commit SHA>..<master change 2 SHA> 

Then later I merge 1.7 / back with master / because I want all the changes made to 1.7 / (except for the cherry pieces) to be merged back to the main line:

 $ git checkout master $ git merge 1.7 

My problem is that this re-commits cherry picks (originally from master /) to master / again:

 $ git log --oneline 8ecfe22 Merge branch '1.7' fe3a60d master change 2 (cherry picked from commit f5cca9296e45d5965a552c45551157ba 9c25f53 master change 1 (cherry picked from commit 8fae2a68a356f5b89faa8629b9a23b23 f5cca92 master change 2 8fae2a6 master change 1 ffa10bf initial commit 

In my real repository, it even caused merge conflicts.

So my question is: can I avoid this (and if so, how)?

A complete list of commands to reproduce this behavior:

 $ git init <create Dialog.js file> $ git add Dialog.js $ git commit -am "initial commit" $ git branch 1.7 <edit Dialog.js file> $ git commit -am "master change 1" <edit Dialog.js file> $ git commit -am "master change 2" $ git log $ git checkout 1.7 $ git cherry-pick -x <initial commit SHA>..<master change 2 SHA> $ git checkout master $ git merge 1.7 $ git log 

Answer 1

When you select cherry, if you do not use the -ff fast-forward -ff , you create new commits, and when you merge back, git should merge with these commits, even if they may not work effectively.

Rebase can help you here instead of merging:

 git rebase master 1.7 

and then merge the branch now (if necessary.)

Cherry-pick is best used when you want to get small changes from a branch that you otherwise drop. Your workflow should be based on merging or reordering as needed.