A quick look at Git cherry-picking

I grew up when tape decks were still a thing. When I was even younger than that, I have memories of using our old turntable in the lounge and putting on whatever record my parents we’re listening to at the time (most often Sgt. Pepper’s Lonely Heart’s Club Band by The Beatles… what an awesome album).

With a tape deck, one had to fast-forward or rewind through all the other songs to arrive at the song of choice. While there were some tape decks that were intelligent enough to know when a song was finished, I don’t remember these catching on too well.

Much like a cassette tape or a record being played through from the start, a Git tree is, at its essence, the same; a record of commits, controlled by a playhead. These commits are “played” onto the tree in a specified order.

Get to the cherry-picking

At Woo, we have a stack of development projects running at any given time. Each project consists of multiple branches, being worked on by different developers and often across various forks. Invariably, pull requests go to the incorrect branch, some may include extra commits that are already in the destination branch, etc. Amongst the standard “push, pull, fetch, merge, checkout, branch” commands, I’ve picked up a few neat tricks to circumvent these kinds of muddled pull request scenarios. The latest of these is cherry-picking (something I’ve been looking for a reason to explore for a while now).

So what is this cherry-picking thing anyways?

Cherry-picking, in Git, is the process by which you re-play a specific commit (regardless of branch) on top of the current branch you have checked out. Pretty nifty, right?

In the scenario I used to learn this technique, I was merging in a wonderful pull request on an internal project from one Mr. Scott Basgaard. His pull request included a few commits I’d already taken care of, so I wanted to merge one or two specific commits before closing the pull request. Cherry-picking to the rescue!

A few quick steps

  1. Make sure you have a local copy of the branch containing the commit(s) you want to cherry-pick. This local branch can track any remote (it doesn’t have to be origin).
  2. Find the full SHA hash of the commit you want to cherry-pick. The git log --oneline is really useful for this.
  3. Checkout the branch you want the cherry-picked commit to be played on top of.
  4. Cherry-pick your commit with git cherry-pick 12345, where 12345 is the full SHA hash you copied in the previous step.

And that’s all there is to it for some basic Git cherry-picking. I hope y’all find this command as useful as I have.


Comments

4 responses to “A quick look at Git cherry-picking”

  1. How does this work with conflicts? Will it still ask you to merge conflicts?

    I could see it being pretty complex if a commit removes a line of code that never existed or something like that.

    1. It looks like git cherry-pick treats these commits as a normal merge. If there would be a conflict, it merges the commit and then marks the conflict without committing the changes. The conflicting files would then need to be staged again.

      If the line of code never existed, and was being removed by a cherry-picked commit, I’m sure that would be fine, as both the commit and the current playhead wouldn’t want the line of code in there. ๐Ÿ™‚

      1. Sounds hairy haha. I’ll avoid it if I can.

        1. It’s not hairy. It’s basically the same as merging two branches, except you’re merging a specific commit instead of a whole branch. ๐Ÿ™‚

Leave a Reply

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