understanding git cherry-pick

Question

Coming from an svn background: I hardly ever branched, due to the (lack of) speed of switching and the hour or more it took to merge branches back into the trunk. Sometimes, if I needed to hotfix a problem on a web site, I'd make the change in the trunk (which would live along with previous changes or new features) and then go to that file and just do "svn up path/to/filename" and it would update only that file, fixing the problem but sparing the rest of the files.

Conceptually, this doesn't seem possible in git (or necessary); is it structured staging and grouped commits that allow for cherry-picking? So, I might change a specific area of the site and commit it as a group instead of doing how I work with svn, and go about a day's work and touch files all over the commit the whole batch at once?

Answer 1

What you probably want to do in this case is make a new branch for your hotfix, branching off of the common ancestor of all branches which will need the fix. For example, suppose you have a couple maintained releases along with your current development:

- X - o - o - o - o - o - o - o - o - o (master)
   \                       \
    o - o - o (release A)   o - o (release B)

If you need to make a hotfix which will apply to both releases, create a branch starting from the commit labeled X. Commit your fix, then merge that branch into all three branches.

You could cherry-pick, but here's a good rule of thumb about when to cherry-pick: don't. The only case in which you will want to cherry-pick is when you've managed your branches badly. In this case, that might mean that you made the fix on master instead of properly branching it off from an earlier point, and people have already pulled the updates to master, so you can't change it. You'd have to cherry-pick to get it on the two release branches. But of course, you should just manage your branches right in the first place, and you'll never need to cherry-pick. (Yes, it'll still happen sometimes; such is life.)