Today, I came across the need for a function that would make most source control mechanism’s cry.  Essentially I needed some work that was due to go into production in a few weeks, to go today, which meant I somehow had to grab some code that was deep down in my bleeding edge branch out into the limelight of the live server.

In Subversion, this would be pain, but luckily I’m using Git.

Out of the box, git comes with a very useful command cherry-pick.  Essentially what this does is take one single commit, and then merges just those changes into the other branch.  This is different to a regular merge in that it doesn’t pull ALL changes, so it’s much more precise.

git cherry-pick -n [The commit's SHA-1 Hash]

(Note that the -n option should be used when you don’t want Git to automatically commit the change into the new branch, but you should make sure your new commit message references the old commit for sanities sake).

Remember though, your newly merged into branch might not be working perfectly now, as you may now have unsatisfied dependencies, so test, test test!

Bookmark It

This is here more as a future note to myself, but hopefully someone out there will find this useful.

Essentially, imagine this:  You have a remote repository (say, on GitHub), and that repo has many branches.  You clone the repo and end up with the master branch in your local dev environment.  Now what happens if you want to use one of the other branches in the repo?

Well, initially, you’d think you would create the branch locally, and pull the differences down:

git branch production
git checkout production
git pull origin production

but what if master is ahead of production (a likely scenario)?  In this case this won’t work as your local production branch will now contain the changes in the master branch – as that’s where you originated production from on your machine.

What you need to do is:

git checkout -b <local_name_for_branch> <remote_source>/<remote_branch>

git checkout -b production origin/production

Bookmark It