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
- 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).
- Find the full SHA hash of the commit you want to cherry-pick. The
git log --oneline
is really useful for this. - Checkout the branch you want the cherry-picked commit to be played on top of.
- Cherry-pick your commit with
git cherry-pick 12345
, where12345
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.
Leave a Reply