1

I know that we use cherry-pick to get the content from a specific commit into our current branch.

I'll explain a situation and need some help to fully understand cherry-pick and be sure this is the right way to solve my problem.

Imagine we have two developers: Bob and Tom and they worked on same files.

Bob has a solid branch which is already in production.
Tom has some work of future release that Bob does not have.
Bob may also have some work that Tom does not have.
Bob wants Tom's work, but he needs to get one by one and test it before sending to production. Wouldn't 'cherry-pick` overwrite Bob's work ? If yes, what is the right way to proceed in this situation ?

PlayHardGoPro
  • 2,791
  • 10
  • 51
  • 90
  • You should have a separate branch for each step: production, testing, features or development as necessary. – Mad Physicist Feb 06 '18 at 16:37
  • Instead of cherry picking, you should be merging entire feature branches into testing, or rebasing onto if you prefer. – Mad Physicist Feb 06 '18 at 16:39
  • 1
    Yes, `cherry-pick` would overwrite Bob's work, but don't worry...Git will inform you if there is a conflict, just like it would if you were using `merge` or `rebase`. – Jonathan.Brink Feb 06 '18 at 16:40
  • Production = master branch. Is it wrong/bad to push our local feature branch to remote and ask someone to test it ? Why? We have a server for test-only. – PlayHardGoPro Feb 06 '18 at 16:42

1 Answers1

1

I know that we use cherry-pick to get the content from a specific commit into our current branch.

...

Wouldn't 'cherry-pick` overwrite Bob's work?

It might help to understand that cherry-pick does not bring "content" from another commit. It applies changes equal to the patch between another commit and its parent. From the docs (https://git-scm.com/docs/git-cherry-pick):

Apply the changes introduced by some existing commits

(emphasis added).

So just like merging is not expected to overwrite Bob's work, cherry-picking is not expected to overwrite Bob's work. It could be that a change being introduced by cherry-pick would conflict with a change in Bob's work, and that would have to be resolved.

The bigger potential issue is that git will not remember, after the fact, that the commit it creates for Bob is related to Tom's original commit. If you will ultimately combine the branches by rebasing one on top of the other, then it may be ok - because rebase will compare "patch ID" values to decide if it should skip replaying a given commit. If you ultimately combine them by merging, you may have to resolve conflicts that don't make sense.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52