careful using git cherry-pick to grab a commit from a “newer” branch

I just discovered some pretty surprising git behavior:

We had two release branches, lets call them v100 (current production) and v101 (next release candidate).  A bug came up and I squashed it on v101.

Someone then brought up that we should squash that same bug on v100 and release a patch v100.1 to production.  Fine.

To squash the bug, I used ‘git cherry-pick’ to grab the commit I made on v101 and apply it to v100.  This worked as you would expect.

Here’s the bad part: When I next attempted to push v100 to remote, I was prompted to merge changes.  When I then pulled v100 from origin, I was presented with an entire set of commits from v101 performed after v100 had already been “frozen”!!!

I believe the reason these additional commits (from v101) were pulled into v100 has to do with the way that git uses the SHA not only to identify a commit, but to find all the preceding commits.  Here’s a more in-depth discussion:

Be careful picking cherries out there!

Leave a Reply

Your email address will not be published. Required fields are marked *