1

I have a question about cherry-pick. We have a project with two main branches: deploy and develop (that's a simplified but accurate view). Deploy is what we have deployed to our production servers and develop is what we're working on (with feature branches off of develop for individual features/fixes/etc).

We had a commit that was merged into develop from a feature branch (via a GitHub pull request from the individual developer's fork) that we needed to push into production. There were other commits on develop that we didn't want to put into deploy yet, so I did a git checkout deploy && git cherry-pick 049cae3 && git push to grab the one commit we needed. That all worked fine, and the code was pushed to production. However, we have a status dashboard that uses the GitHub API to do a comparison of deploy..develop to see how many commits we have piled up on develop that aren't on deploy. I noticed that the number didn't change, and when I looked at the comparison page on github my cherry-pick'd commit was still showing up in the diff. I'm guessing this is because cherry-pick applies the commit with a new SHA so GitHub doesn't see it as being in both branches - they're two different commits.

This probably isn't a big deal as at some point we'll merge develop into deploy, but then I'll probably have a duplicate commit, right? (and yes, we're doing merges, rebase scares me and I haven't really figured it out yet).

So: given the situation where I needed one specific commit, was cherry-picking the right way to go? If not, what is?

grahamb
  • 887
  • 3
  • 7
  • 22
  • Not directly related to your problem, but you really should learn to `rebase`, otherwise you're just not using Git as effectively as you could be. You can think of it as being the same as cherry-picking, except you pick more than one commit. –  Sep 27 '13 at 00:15
  • How would rebase have helped me in this situation? – grahamb Sep 27 '13 at 18:40
  • 1
    @grahamb: it would not, at least not directly. However, you can now rebase the `develop` branch (with `rebase -i`) so that it starts "after" the new cherry-picked commit (in `deploy`), and omits its own version of that cherry-picked commit. Whether this is a good or bad idea depends on too many other variables to say. – torek Sep 27 '13 at 23:20

0 Answers0