Git Cherry Pick

Recent­ly I ran into a prob­lem on a project where I was work­ing on the wrong branch and com­mit­ted changes. Those com­mits were sup­posed to go else­where and I now I need to get them into the cor­rect branch!

There are a few options to solve this:

  • Merge the incor­rect branch into the cor­rect branch. But I don’t want to that because there are items in the incor­rect branch that I don’t want. So, that’s out.

  • Recre­ate those changes in my work­ing branch and just go on with my day. But that’s a waste of my time and I’m adamant­ly against redo­ing work!

  • Cre­ate a patch and then apply that patch to the new branch. 

All sol­id options but there’s still some­thing better:

$ git cherry-pick

A Sce­nario for Using git-cher­ry-pick #

Let’s review where we’re at in our pre­tend sit­u­a­tion (fol­low along with me, okay?) and then how to solve the prob­lem using git-cherry-pick.

I just cre­at­ed a new com­mit in my repos­i­to­ry, in the branch called some_other_feature. But that’s the wrong branch!

$ git branch
  develop
   master
   my_new_feature
  * some_other_feature
   stage

The new com­mit should be on the my_new_feature branch. I could merge the branch­es but the some_other_feature branch con­tains com­mits and changes that I don’t want in the oth­er branch (they are not ready for merg­ing into any upstream branch­es, like develop or master.

Here’s the com­mit I need to get into my_new_feature:

  commit ec485b624e85b2cad930cf8b7c383a134748b057
  Author: Ryan Irelan <[email protected]>
  Date:   Fri Aug 19 10:44:47 2016 -0500
	
  new contact page

Using git-cher­ry-pick #

The syn­tax of git-cher­ry-pick is this:

$git cherry-pick [commit hash]

The first step is fetch the com­mit hash for the com­mits we want to cher­ry-pick. We can do that using git-log and then copy­ing the hash (in full or just the last 7 char­ac­ters will work) to our clipboard.

Next, we need to be on the branch where we want the changes to be (our des­ti­na­tion branch).

$ git checkout my_new_feature

Now we can run the git-cherry-pick com­mand and apply the com­mit to our des­ti­na­tion branch.

  $ git cherry-pick ec485b624e85b2cad930cf8b7c383a134748b057

This will return some­thing like this:

  [my_new_feature 1bf8955] new contact page
  Date: Fri Aug 19 10:44:47 2016 -0500
  1 file changed, 1 insertion(+)
  create mode 100644 contact.html

If we look at our log for this branch, we now see our commit:

	$ git log
  commit 1bf8955d5e6ca71633cc57971379e86b9de41916
  Author: Ryan Irelan <[email protected]>
  Date:   Fri Aug 19 10:44:47 2016 -0500
	
    new contact page

What’s hap­pen­ing when we run git-cherry-pick?

  • Git is fetch­ing the changes in the spec­i­fied com­mit and replay­ing them in the cur­rent branch. The com­mits are not removed from the source branch; they remain intact.
  • Because this com­mit is being applied to a new branch and there­fore has dif­fer­ent con­tents it will get a dif­fer­ent hash than the source commit.

With the prob­lem solved, we are ready to move on with our devel­op­ment work!